execution of post_action each time breaks a keepalive connection to upstream

[Sergey Brester]

> 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 :)