W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: 1xx response semantics

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 05 Jul 2011 17:51:37 +1200
Message-ID: <4E12A669.9050202@treenet.co.nz>
To: ietf-http-wg@w3.org
On 05/07/11 17:14, Willy Tarreau wrote:
> Hi Mark,
> On Tue, Jul 05, 2011 at 09:41:59AM +1000, Mark Nottingham wrote:
>> One (of many) of the issues with 1xx responses is that people don't know how to surface two responses to one request in APIs and tools.
>> I think we could make things a bit easier for folks if we stated that the headers in a 1xx response are semantically not significant; i.e., it's OK for APIs, etc. to drop them on the floor, because the only information is in the status code.
>> This would mean that people shouldn't put headers on a 1xx response and expect applications to see them -- which I think is already the case today.

Yes. HTTP/1.0 middleware will completely drop 1xx responses in certain 
situations. HTTP/1.1 obeying the rules of passing on things it does not 
understand should usually relay, but since it is not spec'd as required 
behaviour may also drop.

FWIW: Squid will treat headers attached to a 100 the same as any 2xx 
when relaying.

> It's not exact because of 101 which should contain at least Upgrade and
> Connection: Upgrade. In fact, 101 is a final status while 100 is an
> intermediate one.
> Maybe we should indicate that "headers are not significant on intermediate
> responses such as 1xx, and are only meaningful on final responses such as
> all other ones, including 101" ?

Its always puzzled me why Upgrade got 101 while CONNECT gets 200. They 
are not that dissimilar.

Received on Tuesday, 5 July 2011 05:52:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC