Hi,
I have done a bit of investigation into bug 70279 and I'm at a point where
I need an opinion of somebody with fastcgi experience.
The bug was caused by f20118aa669f9992fee8a64024e623805669391b (
https://github.com/php/php-src/commit/f20118aa669f9992fee8a64024e623805669391b)
which IMHO has a misunderstanding of what fcgi_init_request does, at least
in the context of how FPM is using it (which is why I'm coming here - it's
unclear to me what other uses of FastCGI are there):
FPM only calls fcgi_init_request once (via fpm_init_request) after it has
spawned a handler process. Then it continues to call fcgi_accept_request to
actually do the request handling.
However, above commit assumes different semantics: It assumes that
fcgi_init_request is called before handling every request. It doesn't in
FPMs case, so FPM is processing requests with some state from the previous
request (like the request headers).
Again, I'm not sure who's correct now: The fastcgi API as it's used since
above commit or FPM (calling init only once). Depending on this
information, the patch would either be more or less undoing the commit or
calling fcgi_hash_clean in fcgi_read_request, though that would more or
less undo the performance optimization anyways.
If somebody with FPM/FastCGI experience could help me here then I'll gladly
provide a patch and tests.
Philip
Sensational AG
Giesshübelstrasse 62c, Postfach 1966, 8021 Zürich
Tel. +41 43 544 09 60, Mobile +41 79 341 01 99
info@sensational.ch, http://www.sensational.ch