*From: *Willy Tarreau <[email protected]> *Sent: * 2014-05-02 02:02:11 E *To: *Rachel Chavez <[email protected]> *CC: *[email protected] *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. If the response depends on the request payload, the server doesn't know whether to respond with 200 or with a 400. 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" > >> In the session.c file starting in 2404 i make sure that if I haven't >> received the entire body of the request I continue to wait for it by >> keeping AN_REQ_WAIT_HTTP as part of the request analyzers list as long as >> the client read timeout hasn't fired yet. > It's unrelated unfortunately and it cannot work. AN_REQ_WAIT_HTTP is meant > to wait for a *new* request. So if the client doesn't send a complete > request, it's both wrong and dangerous to expect a new request inside the > body. When the body is being forwarded, the request flows through > http_request_forward_body(). This one already tests for the client timeout > as you can see. I'm not seeing any error processing there though, maybe > we'd need to set some error codes there to avoid them getting the default > ones. > >> In the proto_http.c file what I tried to do is avoid getting a server >> timeout when the client had timed-out already. > I agree that it's always the *first* timeout which strikes which should > indicate the faulty side, because eventhough they're generally set to the > same value, people who want to enforce a specific processing can set them > apart. > > Regards, > Willy >
