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). 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. Any optinion on this ? Willy
