httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: mod_proxy_fcgi, 304 responses and bogus error messages
Date Tue, 12 Jul 2016 10:26:37 GMT
2016-07-11 23:33 GMT+02:00 Luca Toscano <toscano.luca@gmail.com>:

>
>
> 2016-07-11 19:44 GMT+02:00 Jacob Champion <champion.p@gmail.com>:
>
>> On 07/11/2016 08:53 AM, Luca Toscano wrote:
>>
>>> I am looking for some feedback about the patch proposed to figure out if
>>> I am on the right track or not. Does it make sense to read all the data
>>> returned by a FCGI backend even on error conditions to avoid subsequent
>>> spurious reads or is there a smarter method?
>>>
>>
>> (following up from IRC)
>>
>> Regarding your patch: I think that, rather than duplicate the jump back
>> to recv_again, the error handling logic around the call to
>> ap_scan_script_header_* should be improved. That function is documented to
>> return binary success/failure (OK/INTERNAL_SERVER_ERROR), but in reality it
>> can return other things too -- definitely NOT_MODIFIED (which is handled),
>> perhaps PRECONDITION_FAILED (which is not handled), and maybe others?
>>
>

I followed up on the 412 use case (HTTP_PRECONDITION_FAILED) trying to
reproduce it. mod_proxy_fcgi logs correctly a 412 in the access log (as
opposed to a 503 for the HTTP_NOT_MODIFIED use case) plus the following:

[proxy_fcgi:error] [pid 12325:tid 139974709171968] [client ::1:56696]
AH01070: Error parsing script headers
[proxy_fcgi:error] (22)Invalid argument: [client ::1:56696] AH01075: Error
dispatching request to :

It looks a bit confusing to me, if we want to remove them we might threat a
412 like a 304 (so no body sent to the client, no break in the code since
there might be some more remaining bytes to read).

Luca

Mime
View raw message