httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luca Toscano <toscano.l...@gmail.com>
Subject Re: svn commit: r1754732 - /httpd/httpd/trunk/modules/proxy/mod_proxy_fcgi.c
Date Tue, 02 Aug 2016 12:59:33 GMT
2016-08-02 10:48 GMT+02:00 Yann Ylavic <ylavic.dev@gmail.com>:

> On Tue, Aug 2, 2016 at 8:22 AM, Luca Toscano <toscano.luca@gmail.com>
> wrote:
> >
> > So IIUC you are saying to always done+break in the 304 use case (to avoid
> > reading from the connection again), and then detect the response in
> another
> > place.
>
> Yes, any following data is for the next request.
>
> > Would you mind to give me some indication about where this check
> > should be? I am reviewing the code but it is not straightforward to me
> where
> > to make this change.
>
> IMHO it belongs in ap_proxy_is_socket_connected(), see r1750392 (and
> follow up r1750474).
>

Nice! I didn't remember about this new functionality and didn't think about
using it for my use case.


> If this is in place (trunk only for now), we can simply done+break on
> 204 or 304 in mod_proxy_fcgi


I'd prefer to think about this change as a near-future backport proposal
since it is really annoying for people using mod_proxy_fcgi in big
production environments (bogus 503s and entries in the error logs for 304s
all the time).

I tried the following patch http://apaste.info/qgK (that afaiu should
leverage the code that you pointed out) and tested again my use case
http://apaste.info/n6V (contains php test script, httpd proxy conf and curl
requests) getting a weird result, namely an alternation of 304 and 200
status codes (as opposed to 304 all the times). From the logs (
http://apaste.info/jhF) it seems that the second curl request reads the
whole response rather than discarding it.

Should this be already part of ap_proxy_is_socket_connected or is it still
to be added? My relatively new experience with proxy_util.c does not help a
lot :)



> 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.

Thanks a lot!

Regards,

Luca

Mime
View raw message