httpbis-p2 : 1xx messages may not always be treated as 100

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