Read and Write buffers

Help
1

I have a question about buffers. Consider this:

reverse_proxy localhost:8080 {
    read_buffer 32kb
    write_buffer 32kb
}

Are these buffers used when only reading from client (read) and writing to upstream server (write) or the other way too, so reading from the upstream (read) and writing/sending to client (write)?

So, can the client be bothe the user connecting to caddy and the upstream?

With Nginx, this seems more clear using client_body_buffer_size (reading from client) and proxy_buffers (to upstream).

Thanks :blush:

2

That config isn’t correct, those options are for the http transport so you’d need to put that within transport http.

That’s config only for the connection to the upstream, it’s not connected to behaviour with the originating client. Hence why the config is in the reverse_proxy and not elsewhere.

Why do you think you need to change this? What problem are you trying to solve?

Please fill out the help topic template as per the forum rules.

1 Like
3

Hi Francis, thanks for the reply.

I’m not trying to solve any specific problem yet, just studying Caddy to migrate from Nginx.

Nginx docs seem to be more clear, because it clearly states, for each param, if it is conencted to either client or the upstream.

See Module ngx_http_core_module (an param around) it always states either client or upstream in the param description, which seems a good practice.

Maybe something to consider in the future on Caddy :wink:

4

The docs do state (emphasis mine):

  • transport defines how to communicate with the backend. Default is http.

—reverse_proxy (Caddyfile directive) — Caddy Documentation

All configuration within the transport subdirective of reverse_proxy regards upstream communication. This one just comes down to context.

The equivalent in Caddy is request_body.

Manipulates or sets restrictions on the bodies of incoming requests.

—request_body (Caddyfile directive) — Caddy Documentation

1 Like
5

Sure, it is specified once at the top of the configuration section on which params apply, I got it.

Just saying that having a clear description on each individual param is better docs, IMHO :wink:

6

Are you saying all of these dot points need elaboration like “[…] when communicating with the backend” or something?

image
image468Ă—1577 131 KB

Like, on every single one? Despite the fact they’re all in an upstream-specific section?

I mean - I really don’t think so, myself, but… Here’s the github link: website/src/docs/markdown/caddyfile/directives/reverse_proxy.md at master · caddyserver/website · GitHub

You could submit a pull request for that, I suppose.

2 Likes