[PATCH] Upstream: avoid closing client conn when no response body needed

[Justin Li]

Another mistake in the message... that proxy_cache_bypass should be
proxy_no_cache.

I'm not sure I understand exactly how this was functioning beforehand. In
the case of a cacheable response, if downstream_error is 1, then
won't ngx_event_pipe_drain_chains be called? Why does that case not have
the same issues with busy buffers as previously described?

--
Justin Li
Developer @ Shopify

On Tue, Mar 8, 2016 at 9:29 PM, Justin Li <jli.justinli at gmail.com> wrote:

> # HG changeset patch
> # User Justin Li <jli.justinli at gmail.com>
> # Date 1457490530 18000
> #      Tue Mar 08 21:28:50 2016 -0500
> # Node ID e9f916f271b86e446c6f1de371832432a9f2a66d
> # Parent  c5f81dcf97a79576138917501c9a6cc6f53ee930
> Upstream: avoid closing client conn when no response body needed
>
> If proxy_cache is enabled, and proxy_cache_bypass tests true, it was
> previously
> possible for the client connection to be closed after a 304. The fix is to
> recheck r->header_only after the final cacheability is determined, and end
> the
> request if no longer cacheable.
>
> diff -r c5f81dcf97a7 -r e9f916f271b8 src/http/ngx_http_upstream.c
> --- a/src/http/ngx_http_upstream.c      Thu Mar 03 21:14:19 2016 +0300
> +++ b/src/http/ngx_http_upstream.c      Tue Mar 08 21:28:50 2016 -0500
> @@ -2861,6 +2861,12 @@ ngx_http_upstream_send_response(ngx_http
>          ngx_http_file_cache_free(r->cache, u->pipe->temp_file);
>      }
>
> +    if (r->header_only && !u->cacheable && !u->store) {
> +        u->pipe->downstream_error = 0;
> +        ngx_http_upstream_finalize_request(r, u, rc);
> +        return;
> +    }
> +
>  #endif
>
>      p = u->pipe;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160308/aab98b02/attachment.html>