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

Re: 1xx response semantics

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 6 Jul 2011 10:19:40 +1000
Cc: httpbis Group <ietf-http-wg@w3.org>
Message-Id: <817C712C-400E-44B7-ADD3-13A4E491B695@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>, Roy Fielding <fielding@gbiv.com>

On 05/07/2011, at 5:41 PM, Julian Reschke wrote:

> On 2011-07-05 01:41, 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.
>> Thoughts?
>> ...
> This is news to me. Where does the spec say that right now?

It doesn't. However, I've seen several implementations that don't expose the headers of a 1xx response, and there's also been a discussion of how to integrate 1xx into SPDY as something other than another full response with headers.

> Note that the status code 102 defined in RFC 2518 used the "status-uri" header code, and I believe something similar was proposed for the "progress" status code discussed over here not so long ago.

Ah. The 101 Switching Protocols approach isn't too much of a concern (if someone has the ability to get another protocol supported by a client, they can get access to as much of the response as they need), but I'd forgotten about Status-URI.

Roy said:

> They are significant.  I don't understand why anyone would think they
> are not significant -- the fields are the only way to carry information
> in the interim response other than the status code.

They're significant to the specific semantics of the status code, but what I was trying to say was that someone shouldn't define a new header and expect to be able to grab it off of, for example, a 100 response.

What do people think about adding text to the "Considerations for New Headers" section stating that headers may not be available on 1xx responses in some implementations?


Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 6 July 2011 00:20:21 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:47 UTC