https://bz.apache.org/bugzilla/show_bug.cgi?id=59838
Bug ID: 59838
Summary: mod_proxy_fcgi and AH01068 Got bogus version X error
message
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy_fcgi
Assignee: [email protected]
Reporter: [email protected]
Created attachment 34028
--> https://bz.apache.org/bugzilla/attachment.cgi?id=34028&action=edit
Force httpd to read the whole response from a FCGI backend even in presence of
errors
Hi! This is a follow up for
https://bz.apache.org/bugzilla/show_bug.cgi?id=57198
Recently I tried to track down the following error logs:
[proxy_fcgi:error] [pid 12210:tid 139857489786624] [client ::1:56442] AH01068:
Got bogus version 103
[proxy_fcgi:error] [pid 12210:tid 139857489786624] (22)Invalid argument:
[client ::1:56442] AH01075: Error dispatching request to :
I am running httpd 2.4.10 (Debian Stable) so I tried to backport some patches
to solve the issue with no luck:
- http://svn.apache.org/r1642855
- http://svn.apache.org/r1726019
- http://svn.apache.org/r1650677
So I tried to reproduce in httpd-trunk. Thanks to
https://bz.apache.org/bugzilla/show_bug.cgi?id=57198 I was able reproduce,
simply issuing a big enough php response that leads to a 304. I attached a
simple patch that solves the problem, but I am not expert enough to be sure
that it wouldn't trigger undesired side effects.
The idea is that if iobuf_size is smaller than clen (the length of the FCGI
response), then in presence of a non HTTP_OK response (so even a
HTTP_NOT_MODIFIED) mod_proxy_fcgi will not try to read the whole response due
to a break in the code. For example:
1) FCGI response size/clen:10705 iobuf_size: 8192
2) mod_proxy_fcgi sees a POLLIN event, reads the FCGI headers finding a
AP_FCGI_STDOUT type FCGI record. readbuflen is 8192
3) mod_proxy_fcgi establishes that the response is a 304 (HTTP_NOT_MODIFIED)
and flushes the HTTP headers that gets to the client correctly.
4) At this point mod_proxy_fcgi "break"s because it is supposed to not send the
304 response body but it forgets to clear the remaining 10705 - 8192 bytes
still pending to read.
5) mod_proxy_fcgi still sees a POLLIN event for the 10705 - 8192 bytes, and
tries to read the FCGI record headers. The data is of course not a valid header
so mod_proxy_fcgi recognizes a wrong version and starts the error procedure,
namely logging the aforementioned AH01068 and AH01075 errors plus a 503 in the
access logs.
So the 304 without the body gets correctly to the client, but httpd thinks it
was an error and logs a 503 + scary error messages instead.
Looking forward go get some feedback!
Thanks,
Luca
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
