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.
It's a proper pity if that some day gets the chop :(
Because I see no really options to easy realize it (with any current
advantages) as module without great integrity in nginx core.
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.
I know that all... And both fsgi upstreams work proper (header only
also) and sends end-request record hereafter. (Just checked again).
The problem is that it does not "wait" (I know it's not really wait) for
proper endrequest and does not set u-keepalive to 1, so worker closes a
connection.
But I will find it out and fix anyway :)
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
