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 14:07:43 GMT
2016-08-02 15:23 GMT+02:00 Yann Ylavic <ylavic.dev@gmail.com>:

> On Tue, Aug 2, 2016 at 2:59 PM, Luca Toscano <toscano.luca@gmail.com>
> wrote:
> >
> > 2016-08-02 10:48 GMT+02:00 Yann Ylavic <ylavic.dev@gmail.com>:
> >>
> >> 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.
>

I will do some research but afaik it should be always present. Any other
opinion from the list?


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

This was exactly what I way trying to do with this commit, but only when
the connection is reused. It has an annoying downside, like introducing a
bit of latency between the HTTP headers flush to the client and the end of
the request for the use case described below (but it works 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).
>

There is one case in which a mod_proxy_fcgi returns a 304 but there is also
body to read/process, namely when a "regular" FCGI response is returned by
a backend script with a Last-Modified header and the client uses something
like If-Modified-Since. In this case ap_scan_script_header_err_brigade_ex
(through ap_scan_script_header_err_core_ex -> ap_meets_conditions) sets the
"status" variable in mod_proxy_fcgi to HTTP_NOT_MODIFIED, but the
message-body has been sent anyway. I am not sure if the FCGI script would
be in violation of the RFC behaving like this but if not it is a valid use
case.

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

+1,  I agree 100%


Regards,

Luca

Mime
View raw message