Hello,
I have a question about NGINX configuration as an HTTP reverse proxy with proxy_buffering set to "on".
What is the reason for the existence of proxy_buffer_size? In other words, why would you want NGINX to treat the http header separately from the body?
I realize that chunked encoding and variable response generation time might be at play, but my expectation is that IF the upstream server sends the header and body without delay over a fast LAN, or IF the upstream server packs the header and body into 1 TCP packet, then we might want the NGINX reverse-proxy to buffer the entire HTTP response together and pack the TCP packet send to the client, as opposed to sending 2 TCP packets on the wire, even if tcp_nodelay is "on".
Does HTTP/1.1 require an upstream HTTP server to send the HTTP header and body in 2 TCP chunks? What am I missing here?
Thanks for your help.
I have a question about NGINX configuration as an HTTP reverse proxy with proxy_buffering set to "on".
What is the reason for the existence of proxy_buffer_size? In other words, why would you want NGINX to treat the http header separately from the body?
I realize that chunked encoding and variable response generation time might be at play, but my expectation is that IF the upstream server sends the header and body without delay over a fast LAN, or IF the upstream server packs the header and body into 1 TCP packet, then we might want the NGINX reverse-proxy to buffer the entire HTTP response together and pack the TCP packet send to the client, as opposed to sending 2 TCP packets on the wire, even if tcp_nodelay is "on".
Does HTTP/1.1 require an upstream HTTP server to send the HTTP header and body in 2 TCP chunks? What am I missing here?
Thanks for your help.