On Mon, Apr 14, 2014 at 12:08:40PM -0400, Patrick Hemmer wrote: > >> 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).
Yes, but this was not meant for anyone to pick unregistered codes, but for the protocol to be extensible. More info here : http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-8.2 8.2. Status Code Registry The HTTP Status Code Registry defines the name space for the response status-code token (Section 6). The status code registry is maintained at <http://www.iana.org/assignments/http-status-codes>. And 8.2.2 is even clearer about this : Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely. There was never any consensus for having a range of "free" status codes just like is done with headers starting with "X-" unfortunately. > > 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 :-) The problem is that people who documented HTTP in the past didn't necessarily know by then that TCP was two half-connections and not a single full one. Unless you have a hard error on a socket, you never know if the other side is closed and TCP offers no provisions for this. TCP only says "that's all I have to say" (ie: FIN). In practice, many scripts or even health checks from various systems do send a request with a FIN immediately because they have nothing more to say. It will become even more common with TCP FastOpen where it's very convenient to send SYN+request+FIN in a single packet and receive the response along with the SYN-ACK and a FIN as well. Almost UDP! > 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" I thought about it, but 417 has a very specific meaning related to the Expect header and will definitely have side effects when sent in response to a request having an Expect header (such as the client not being able to reformulate the request ever). > Would it be difficult to add a parameter to the option? Such as "option > httpclose 417" to control how haproxy responds? It's an idea that is worth thinking about. It would be for abortonclose though, but the idea is there. One thing I don't like with overloading options is that in the past they were plain booleans and were cancellable with "no" in front of them. As time goes, some options take extra args which make them harder to cancel, or more confusing. Maybe we could do something even better, consisting in enumerating the long list of all events which lead to a fixed status code and make it possible to remap them. I'm pretty sure that for some users it might be really nice, even if it allows some to write stupid configurations. Regards, Willy
