|Summary:||mod_proxy_fcgi wrong behavior with 304|
|Product:||Apache httpd-2||Reporter:||Alexander Strange <astrange>|
|Component:||mod_proxy_fcgi||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
Description Alexander Strange 2012-03-11 06:26:16 UTC
I have a PHP script (run as fastcgi through php-fpm and mod_proxy_fcgi) which returns a Last-Modified header with no Status header. At line 746: http://svn.apache.org/viewvc/httpd/httpd/tags/2.4.1/modules/proxy/mod_proxy_fcgi.c?revision=1243503&view=markup ap_scan_script_header_err_brigade_ex returned HTTP_NOT_MODIFIED. This caused the 'status != OK' check to fail and it returned 200 with an empty body. Seems related to bug 38070.
Comment 1 Stefan Fritsch 2012-04-21 17:52:35 UTC
Can you please check if this patch fixes the problem? http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c?r1=1311172&r2=1311171&pathrev=1311172
Comment 2 Alexander Strange 2012-04-27 04:27:30 UTC
2.4.2 + that patch appears to work.
Comment 4 BC dev team 2013-03-26 03:11:59 UTC
We have been chasing an issue with Apache 2.4.2 and found this bug report. We upgraded to 2.4.4. This change appears to partially fixed the issue in that upon a 304 response apache now returns content. However we are still seeing an error message logged in the following format - "[proxy_fcgi:error] [pid 1226:tid 139673091413760] [client 10.1.2.1:58133] AH01070: Error parsing script headers". Upon inspection of the code we think we can see that this message will be reported when ANYTHING but a 200 OK is generated. Ideally we dont want to see the error in our apache logs. Can someone investigate?
Comment 5 Luke G. 2014-09-04 18:40:19 UTC
The patch r1331416 introduced a serious bug: In the case described by the original poster (a PHP script run as fastcgi through php-fpm and mod_proxy_fcgi which returns a Last-Modified header with no Status header), Apache does indeed now return a 304 status (if a matching If-not-modified header is in the request) BUT the content of the php script is also sent. This breaks the http protocol as described in rfc2616 section 10.3.5: "The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields." This cause us a serious problem when this kind of request is sent through our reverse proxy placed just in front of the backends. When the proxy receives this (invalid) 304 response, it immediately sends a 304 to the client and ignores the rest of the packet; but the next packets sent by the backend stay in the tcp stack (the proxy does not expect further content). The reverse proxy prepends these packets in the response to the next request routed to the same backend. This, of course, breaks our applications... Can someone suggests a patch we could test to fix this problem?
Comment 7 Eric Covener 2014-12-04 14:52:57 UTC
marking fixed, followup in 57198