execution of post_action each time breaks a keepalive connection to upstream
mdounin at mdounin.ru
Thu May 7 16:17:44 UTC 2015
On Thu, May 07, 2015 at 05:37:44PM +0200, Sergey Brester wrote:
> >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
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()
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:
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.
More information about the nginx-devel