httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Date Tue, 02 Aug 2016 13:23:39 GMT
On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano <> wrote:
> 2016-08-02 10:48 GMT+02:00 Yann Ylavic <>:
>> 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

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.


View raw message