Hi Patrick,
On Fri, May 02, 2014 at 10:57:38AM -0400, Patrick Hemmer wrote:
> *From: *Willy Tarreau <w...@1wt.eu>
> *Sent: * 2014-05-02 02:02:11 E
> *To: *Rachel Chavez <rachel.chave...@gmail.com>
> *CC: *haproxy@formilux.org
> *Subject: *Re: please check
>
> > On Thu, May 01, 2014 at 03:44:46PM -0400, Rachel Chavez wrote:
> >> The problem is:
> >>
> >> when client sends a request with incomplete body (it has content-length but
> >> no body) then haproxy returns a 5XX error when it should be a client issue.
> > It's a bit more complicated than that. When the request body flows from the
> > client to the server, at any moment the server is free to respond (either
> > with an error, a redirect, a timeout or whatever). So as soon as we start
> > to forward a request body from the client to the server, we're *really*
> > waiting for the server to send a verdict about that request.
> At any moment the server is free to respond yes, but the server cannot
> respond *properly* until it gets the complete request.
Yes it can, redirects are the most common anticipated response, as the
result of a POST to a page with an expired cookie. And the 302 is a
clean response, it's not even an error.
> If the response depends on the request payload, the server doesn't know
> whether to respond with 200 or with a 400.
With WAFs deployed massively on server infrastructures, 403 are quite
common long before the whole data. 413 request entity too large appears
quite commonly as well. 401 and 407 can also happen when authentication
is needed.
> RFC2616 covers this behavior in depth. See "8.2.3 Use of the 100
> (Continue) Status". This section indicates that it should not be
> expected for the server to respond without a request body unless the
> client explicitly sends a "Expect: 100-continue"
Well, 2616 is 15-years old now and pretty obsolete, which is why the
HTTP-bis WG is working on refreshing this. New wording is clearer about
how a request body is used :
o A server MAY omit sending a 100 (Continue) response if it has
already received some or all of the message body for the
corresponding request, or if the framing indicates that there is
no message body.
Note the "some or all".
It's very tricky to find which side is responsible for a stalled upload.
I've very commonly found that frozen servers, or those with deep request
queues will stall during body transfers because they still didn't start
to consume the part of the request that's queued into network buffers.
All I mean is that it's unfortunately not *that* white and black. We
*really* need to make a careful difference between what happens on the
two sides. The (hard) goal I'm generally seeking is to do my best so
that a misbehaving user doesn't make us believe that a server is going
badly. That's not easy, considering for example the fact that the 501
message could be understood as a server error while it's triggered by
the client.
In general (unless there's something wrong with the way client timeouts
are reported in http_request_forward_body), client timeouts should be
reported as such, and same for server timeouts. It's possible that there
are corner cases, but we need to be extremely careful about them and not
try to generalize.
Best regards,
Willy
