2016-07-11 23:33 GMT+02:00 Luca Toscano <[email protected]>: > > > 2016-07-11 19:44 GMT+02:00 Jacob Champion <[email protected]>: > >> 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
