<div dir="ltr"><div>Thanks for your feedback Maxim!</div><div><br></div>On Wed, Mar 09, 2016 at 01:13:46, Maxim Dounin wrote:<div><br></div><div><div>> So you are trying to optimize a specific case with proxy_no_cache </div><div>> in addition to what 35990c69b3ac fixed, right?</div><div><br></div><div>Yes, as you figured, this is about preventing the client connection from being</div><div>closed when the client response is header_only and the upstream response</div><div>switches from cacheable to not cacheable between the header_only check</div><div>and downstream_error check. Sorry for the vagueness.</div><div><br></div><div>> What about explicitly handling the proxy_no_cache case right </div><div>> after the proxy_no_cache cache check, much like it is already done </div><div>> with cache object (see ngx_http_file_cache_free() call)?</div><div>> </div><div>> (Additionally, the code between the no_cache test and the </div><div>> ngx_http_file_cache_free() call also shows that lack of </div><div>> proxy_cache_valid and/or explicit cache validity headers can lead </div><div>> to the same behaviour.)</div><div><br></div><div>I assume you mean something like calling ngx_http_upstream_finalize_request()</div><div>if (r->header_only && !u->cacheable && !u->store) after the referenced call to</div><div>ngx_http_file_cache_free(). I'll submit another patch after testing to confirm it</div><div>fully fixes our issue unless you object to that interpretation.</div><div><br></div><div>--</div><div>Justin Li</div><div>Developer @ Shopify</div></div></div>