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

On Tue, 6 Jul 2010, Willy Tarreau wrote:

> 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.

In fact, it's not that 100 is a special state, it is more because 101 is 
special.
<<
       - 1xx: Informational - Request received, continuing process
>>
<<
    A client MUST be prepared to accept one or more 1xx status responses
    prior to a regular response, even if the client does not expect a 100
    (Continue) status message. Unexpected 1xx status responses MAY be
    ignored by a user agent.

    Proxies MUST forward 1xx responses, unless the connection between the
    proxy and its client has been closed, or unless the proxy itself
    requested the generation of the 1xx response. (For example, if a
    proxy adds a "Expect: 100-continue" field when it forwards a request,
    then it need not forward the corresponding 100 (Continue)
    response(s).)
>>
The "prior to a regular response" show that 101 is the culprit, and not 
100.

However, 101 definition says:
<<
    The server understands and is willing to comply with the client's
    request, via the Upgrade message header field (section 14.42), for a
    change in the application protocol being used on this connection.
>>
but Upgrade is a hop-by-hop header
<<
    The Upgrade header field only applies to the immediate connection.
    Therefore, the upgrade keyword MUST be supplied within a Connection
    header field (section 14.10) whenever Upgrade is present in an
    HTTP/1.1 message.
>>
Meaning that Upgrade request should not be transmitted by a proxy, unless 
the proxy knows how to deal with 101 and re-add the Upgrade header (and 
act accordingly afterwards).

If the client is sending a Upgrade: header to a proxy not knowing how to 
cope with it, it should be removed, and no 101 can flow back, so the 
general rules of 1xx are still correct.

> 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.

In your case, you are just not supporting 101 and it is fine, unless you 
forward the Upgrade headers.

> 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
>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Friday, 9 July 2010 16:21:25 UTC