execution of post_action each time breaks a keepalive connection to upstream

[Sergey Brester]

Hi all,

I've found that use of "post_action @named_post" always (each time) 
closes a upstream connection (despite of keepalive).

I've been using fastcgi in @named_post. I think it belong somehow to 
"r->header_only=1",
because fastcgi request does not wait for end-request record from 
fastcgi,
so end of request and closing immediately after logging of "http fastcgi 
header done".

Facts are (as debug shows):

  - r->keepalive == 1, but in "ngx_http_upstream_free_keepalive_peer" - 
u->keepalive == 0, so "goto invalid";
    so, saving connection will not be held.

  - I think, that in fastcgi u->keepalive will be set to 1 only by 
processing of end-request record and
    possible neither ngx_http_fastcgi_input_filter or 
ngx_http_fastcgi_non_buffered_filter will
    not executed, but sure is, that line "u->keepalive = 1" will never 
executed for "post_action" request:

         if (f->state == ngx_http_fastcgi_st_padding) {
             if (f->type == NGX_HTTP_FASTCGI_END_REQUEST) {
                ...
                 if (f->pos + f->padding == f->last) {
                     ...
                     u->keepalive = 1;

  - I don't think that is fastcgi only, and that never work, because 
similar
    execution plan used by "auth_request" (header_only also, but all that 
over subrequest)
    and there "u->keepalive" is 1, so it holds resp. saves connection and 
uses it again later.
    But as I said it uses a subrequest, and "post_action" uses 
ngx_http_named_location.

Keep-alive is very very important for me, unfortunately I can not give 
up this.

I can rewrite post_action over subrequest, but imho it's not a correct 
solution for this.

In which direction should I dig to fix this issue ?

Possible it is not "r->header_only", but one of "if (r->post_action) 
..." or anything else, that prevents execution of input_filter...

Any suggestions are welcome...

Regards,
sebres.