httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <>
Subject Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Date Tue, 02 Aug 2016 16:58:18 GMT
2016-08-02 17:54 GMT+02:00 Yann Ylavic <>:

> On Tue, Aug 2, 2016 at 5:05 PM, Yann Ylavic <> wrote:
> >
> > So we need to detect whether the 304 is a CGI Status or ours.
> > It seems that in the former case r->status is 304, whereas in the
> > latter case this is the local variable 'status' only.
> > We could possibly set "cgi_status = r->status" in mod_proxy_fcgi and
> > bail out if anything is read but AP_FCGI_END_REQUEST when cgi_status
> > == [23]04.
> > Otherwise let ignore_body suck up the response body (if any) so that
> > the connection can be reused if all goes well until the next request.
> Actually, unless we want to check/enforce that a Status 304 (as
> opposed to a 304 set by ap_meets_conditions) is not followed by a
> body, the correct behaviour is probably just to revert this commit
> (r1754732).
> We already ignore the body (when we ought to) until
> AP_FCGI_END_REQUEST, and I see no reason to close the connection
> underneath the backend if we turn a 200 to a 304, this connection can
> even be reused if all goes well.
> Enforcing that Status 204/304 has no body is not part of this bugfix I
> guess...

So basically keeping only that avoids to
break before AP_FCGI_END_REQUEST ? The only downside that I see is that in
case a FCGI response turns up into a 304 (the 'status = 304' use case
mentioned earlier) then the HTTP headers are shipped to the external client
very quickly, but then some latency is added because httpd needs to read
all the bytes from the FCGI connection before completing the HTTP response
(at least this is what I have observed in my tests).

If this is ok I can revert r1754732 and leave my backport proposal as it is

Thanks for the patience!


View raw message