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