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