- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 6 Jul 2010 23:29:22 +0200
- To: ietf-http-wg@w3.org
Hello, since at least RFC1945 and up to at least httpbis-p2-9, it is stated in "4. Status Code and Reason Phrase" : HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. I followed that advice about a year ago when adding support for 1xx responses in HAProxy, and that broke status 101 which till then was working without doing anything special. The reason is that 100 is a very special state in that it implies that a second response message follows (possibly a 100 too BTW). 101 is a final message. So by considering that 1xx could all be treated as 100, I broke support for 101 because when a server replied with 101, I would wait for a second message to come. I think that it would be reasonable to add an exception for 1xx messages in the statement above so that other people don't get trapped as I did for the same reasons ("it's enough and I don't need special processing of this one"). This is particularly true on intermediates. I rememeber having noticed that some products don't support 101 (Pound was one of them last year, Alteon used to be too), and it is possible that for some of them, it is due to the same simplification. Any opinions ? Regards, Willy
Received on Tuesday, 6 July 2010 21:29:51 UTC