httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1681199 - /httpd/httpd/branches/2.4.x/STATUS
Date Mon, 25 May 2015 14:27:57 GMT
On Fri, May 22, 2015 at 4:58 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

> Hi Jeff,
>
> On Fri, May 22, 2015 at 9:21 PM,  <trawick@apache.org> wrote:
> >
> > +     trawick: It still looks to me that an error with ap_pass_brigade
> (towards
> > +              client) can turn into a 400 error, which is what I was
> concerned
> > +              about originally.
>
> I don't see where this can happen, but I may be missing something,
> please correct me if I'm wrong.
>
> Whenever ap_pass_brigade() is called, failing or not, the data_sent
> flag is set to 1 (some data have been sent to the client).
> Now outside the loop, in both cases where {client,backend}_failed
> (i.e. any read or write error occured on the {client,backend} side) or
> !request_ended (i.e. the last chunk was not received from the backend,
> yet another misnaming), the final rv will be set to DONE (and won't
> change until return, an error bucket 503 may be used if backend_failed
> but not if the client connection was aborted).
>

I see for fleeting moments that there's a sequence of setting of different
variables to certain values over the function that ensures that
HTTP_BAD_REQUEST is not set if an error occurred writing to the client.
Fun.

I'm sorry for the trouble.


> I agree that the state maintained by as much variables is a mess (the
> code has probably evolved by adding a new one to handle a new case, I
> did not add any in this patch though), and we ought to simplify this,
> but maybe we can leave it as is for 2.4.13 (and fix PR 56823) and
> refactor soon?
> I'd volonteer eventually...
>
> Regards,
> Yann.
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message