On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano <[email protected]> wrote: > > 2016-08-02 10:48 GMT+02:00 Yann Ylavic <[email protected]>: >> >> 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. 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. 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). 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. Regards, Yann.
