Re: 1xx response semantics

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?

Regards,


--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 6 July 2011 00:20:21 UTC