execution of post_action each time breaks a keepalive connection to upstream

[Maxim Dounin]

Hello!

On Thu, May 07, 2015 at 05:37:44PM +0200, Sergey Brester wrote:

> >Hello!
> >
> >On Thu, May 07, 2015 at 12:51:33PM +0200, Sergey Brester wrote:
> >
> >>Hi all, I've found that use of "post_action @named_post" always (each
> >>time) closes a upstream connection (despite of keepalive).
> >
> >In short:
> >
> >- post_action is a dirty hack and undocumented on purpose, avoid
> >using it;
> 
> Undocumented in the long term or just still not?
> Because meanwhile it will be used from "half" world... I know at least a
> dozen companies, using that.

It was never documented, and will never be documented.  Well, may 
be we'll add something like "post_action: don't use it unless you 
understand what are you doing" to let people know that this 
directive should not be used.

> >- as long as an upstream response is complete after receiving a
> >header, upstream keepalive should work even with post_action; it
> >might be tricky to ensure this with fastcgi though.
> 
> What confuses me, that a header_only subrequest to fastcgi works fine!
> And what I mean was, it can be not "post_action" self, but possible all
> "header_only" requests via ngx_http_named_location etc. so in this case many
> things are affected (including third-party modules).

A connections to an upstream server can be only kept alive if it 
is in some consistent state and no outstanding data are expected 
in it.  On the other hand, nginx doesn't try to read anything in 
addition to what it already read during normal upstream response 
parsing.

As a result, if sending of a response is stopped once nginx got a 
header (this happens in case of post_action and in some cases with 
r->header_only), nginx will only be able to cache a connection if 
it's already in a consistent state.  This may be the case with 
HTTP if Content-Length is explicitly set to 0 in the response 
headers and in some other cases (see ngx_http_proxy_process_header() 
for details).

Quick look suggests that with FastCGI it doesn't seems to be 
possible at all, at least with current code, as nginx parses 
headers from FCGI_STDOUT records, but at least a FCGI_END_REQUEST 
record is additionally expected.  Therefore, FastCGI connections 
are always closed after a post_action request.  We event have a 
test for this:

http://hg.nginx.org/nginx-tests/file/f7bc1f74970a/fastcgi_keepalive.t#l66

If you think that a header_only subrequest works for you - well, 
you've probably missed something.  E.g., a header_only subrequest 
can work because of a configured cache.

-- 
Maxim Dounin
http://nginx.org/