mirrors/caddy-website
1
0
Fork 0
mirror of https://github.com/caddyserver/website.git synced 2025-04-21 20:46:15 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

reverse_proxy: Clarify streaming/buffering

Browse source
This commit is contained in:
Matthew Holt 2022-08-29 10:15:26 -06:00
parent 39219c6ea7
commit 8f8a09fcad
No known key found for this signature in database
GPG key ID: 2A349DD577D586A5
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
src/docs/markdown/caddyfile/directives/reverse_proxy.md
View file

@ -289,9 +289,9 @@ Passive health checks happen inline with actual proxied requests:
### Streaming
The proxy **buffers responses** by default for wire efficiency:
The proxy partially buffers and periodically flushes responses by default for wire efficiency:
- **flush_interval** <span id="flush_interval"/> is a [duration value](/docs/conventions#durations) that adjusts how often Caddy should flush the response buffer to the client. By default, no periodic flushing is done. A negative value disables response buffering, and flushes immediately after each write to the client. This option is ignored when the upstream's response is recognized as a streaming response, or if its content length is `-1`; for such responses, writes are flushed to the client immediately.
- **flush_interval** <span id="flush_interval"/> is a [duration value](/docs/conventions#durations) that adjusts how often Caddy should flush the response buffer to the client. By default, no periodic flushing is done. A negative value disables response buffering, and flushes immediately after each write to the client. This option is ignored when the upstream's response is recognized as a streaming response, or if its content length is `-1`; for such responses, writes are always flushed to the client immediately.
- **buffer_requests** <span id="buffer_requests"/> will cause the proxy to read the entire request body into a buffer before sending it upstream. This is very inefficient and should only be done if the upstream requires reading request bodies without delay (which is something the upstream application should fix).