*From: *Willy Tarreau <w...@1wt.eu> *Sent: * 2014-04-14 11:27:59 E *To: *Patrick Hemmer <hapr...@stormcloud9.net> *CC: *haproxy@formilux.org *Subject: *Re: haproxy intermittently not connecting to backend
> Hi Patrick, > > On Sat, Apr 12, 2014 at 01:38:54AM -0400, Patrick Hemmer wrote: >> This just keeps coming back to bug me. I don't think the client closing >> the connection should result in a 5XX code. 5XX should indicate a server >> issue, and the client closing the connection before the server has a >> chance to respond isn't a server issue. Only if the server doesn't >> respond within the configured timeout should it be a 5XX. >> >> Nginx uses 499 for "client closed connection". Perhaps haproxy could use >> that status code as well when `option abortonclose` is used. > It's wrong to invent new status codes, because they'll sooner or later > conflict with one officially assigned (or worse, they'll become so much > used that they'll make it harder to improve the standards). RFC2616 says "HTTP status codes are extensible" and even gives a specific scenario how the client should handle an unregistered code (look for the "if an unrecognized status code of 431 is received by the client" example). > I get your point though. I'm used to say that 5xx is an error that the > client should not be able to induce. This is not totally right nowadays > due to 501, nor due to web services which like to return 500 when they > want to return "false"... But in general that's the idea. > > However here it's not as black and white. If a client manages to close > before the connection to the server is opened, it's generally because > the server takes time to accept the connection. The longer it takes, > the higher the number of 503 due to client aborts. What we should try > to avoid in my opinion is to return 503 immediately. I think that the > semantics of 408 are the closest to what we're expecting in terms of > asking the client to retry if needed, eventhough that's a different > technical issue. I'd rather not use plain 400 to avoid polluting the > real 400 that admins have a hard time trying to fix sometimes. I disagree with the statement that we should avoid immediate response when the connection is closed. Going back to RFC1945 (HTTP 1.0), we have this: "In any case, the closing of the connection by either or both parties always terminates the current request, regardless of its status." But that is HTTP 1.0, so it's validity in this case is tenuous. I couldn't find a similar statement in RFC2616, or anything which states how it should be handled when the client closes it's connection prior to response. I guess this is why it's a configurable option :-) If we want to use a registered status code, I would argue in favor of "417" which has the following in it's description: "if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server" Would it be difficult to add a parameter to the option? Such as "option httpclose 417" to control how haproxy responds? > Any optinion on this ? > > Willy > >
