Ok, quite clear. ) Just thought that in case of keepalive connection to FastCGI upstream we can process more than 1 request using one connect.
Unexpected FCGI_END_REQUEST is received in following case: 1) Request 1 sent to backend, results received and sent to client 2) Request 2 sent to backend by nginx and is in queue because php is busy after fastcgi_finish_request() call 3) php finishes extra work after fastcgi_finish_request() call and sends FCGI_END_REQUEST 4) Nginx expects STDERR or STDOUT of request 2 but receives FCGI_END_REQUEST of request 1. If this situation is normal by design I will just not use keep_conn. Kind regards, Dmitry Saprykin On 4 July 2014 17:23, Maxim Dounin <[email protected]> wrote: > Hello! > > On Fri, Jul 04, 2014 at 05:18:52PM +0400, Dmitry Saprykin wrote: > > > Hello, > > > > This changeset adds support for FastCGI FCGI_END_REQUEST record type. > > Now nginx does not process this type of FastCGI record. > > In case of usage php fastcgi upstream which finishes FastCGI > > requests before end of script using fastcgi_finish_request() call > > it leads to "upstream sent unexpected FastCGI record: 3 while reading > > response header from upstream" error messages and 502 for clients. > > > > Changeset parses FCGI_END_REQUEST FastCGI records and ignores it > > if keep_conn is enabled and record has type FCGI_REQUEST_COMPLETE. > > What makes you think that this is something to be fixed in nginx? > The FCGI_END_REQUEST record is clearly unexpected if there are no > requests in flight. You may want to focus on fixing the problem > in php instead. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel >
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
