2016-08-02 15:23 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: > On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano <toscano.l...@gmail.com> > wrote: > > > > 2016-08-02 10:48 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>: > >> > >> What I don't know is whether or not we need to read AP_FCGI_END_REQUEST > >> anyway? > >> If that's the case, we should indeed not break until then, and > >> conn->close=1+done+break if we read anything else before. > > > > But wouldn't this be like reading the whole response (headers + > > message-body) and then discard what not needed? I am not getting how > would > > we get to the AP_FCGI_END_REQUEST bytes without reading the other ones. > > Actually I don't know if (but I now suppose that) the end of the > response for the current current is marked by AP_FCGI_END_REQUEST, > irrespective of the HTTP status code. >
I will do some research but afaik it should be always present. Any other opinion from the list? > If that's correct, we indeed shouldn't break until we got > AP_FCGI_END_REQUEST, so that we can reuse the connection when all goes > well. > This was exactly what I way trying to do with this commit, but only when the connection is reused. It has an annoying downside, like introducing a bit of latency between the HTTP headers flush to the client and the end of the request for the use case described below (but it works well). > But since it's a 304 (or a 204 which should be handled the same here), > we don't expect any body between the header and AP_FCGI_END_REQUEST, > so if that happens (something else than AP_FCGI_END_REQUEST is read > while ignore_body == 1), we must bail out with conn->close=1 to avoid > reusing the connection for any further request. > If the response header has not been forwarded already, we could either > respond with a BAD_GATEWAY instead or forward it before leaving > (possibly be lenient with CGIs). > There is one case in which a mod_proxy_fcgi returns a 304 but there is also body to read/process, namely when a "regular" FCGI response is returned by a backend script with a Last-Modified header and the client uses something like If-Modified-Since. In this case ap_scan_script_header_err_brigade_ex (through ap_scan_script_header_err_core_ex -> ap_meets_conditions) sets the "status" variable in mod_proxy_fcgi to HTTP_NOT_MODIFIED, but the message-body has been sent anyway. I am not sure if the FCGI script would be in violation of the RFC behaving like this but if not it is a valid use case. In any case we must not forward any body bytes to the client (with > 304/204) or reuse this out of sync connection with the backend later. > +1, I agree 100% Regards, Luca
