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

Re: 1xx response semantics

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 06 Jul 2011 10:30:55 +0200
Message-ID: <4E141D3F.2060500@gmx.de>
To: Willy Tarreau <w@1wt.eu>
CC: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, httpbis Group <ietf-http-wg@w3.org>
On 2011-07-06 10:28, Willy Tarreau wrote:
> On Wed, Jul 06, 2011 at 10:23:13AM +0200, Julian Reschke wrote:
>> On 2011-07-06 10:09, Willy Tarreau wrote:
>>> On Wed, Jul 06, 2011 at 09:41:21AM +0200, Julian Reschke wrote:
>>>> On 2011-07-06 07:14, Willy Tarreau wrote:
>>>>> On Wed, Jul 06, 2011 at 02:43:23AM +0200, Julian Reschke wrote:
>>>>>> On 2011-07-06 02:19, Mark Nottingham wrote:
>>>>>>> ...
>>>>>>> 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?
>>>>>>> ...
>>>>>> Do you have an example of an implementation that *does* expose 1xx
>>>>>> responses, but not the headers on them?
>>>>> Julian, I think I understand what Mark means. It's not much a matter
>>>>> of exposing either the header or the status, but to see how the header
>>>>> will be used. For instance, if you send a "connection: close" on a 100
>>>>> response, it will be ignored by most implementations. If you send
>>>>> "Transfer-encoding: chunked", it should (hopefully) be ignored. If some
>>>>> implementations were to consider such headers, they could adopt a wrong
>>>>> behaviour.
>>>>> ...
>>>> Still not convinced. Maybe it's worth noting that 100 is really a very
>>>> special kind of 1xx, and coming to conclusions about what other 1xx
>>>> codes can do based on what happens with 100 is not going to work?
>>> That would be one solution, but the issue we have with 100 is that any
>>> unknown 1xx should be processed as 100, so it's hard to define it as the
>>> special case.
>> Actually, I meant to say 101, not 100.
>> Using 100 as fallback behavior is ok.
>> So can we agree on a statement like:
>> 	"Many frameworks do not report header fields received with an 1xx
>> status message back to the application, although they should. Thus it
>> may be hard to introduce new 1xx status codes that depend on additional
>> header fields to report information."
> I don't precisely see it that way. Roy gave an example of a header that
> made sense for an interim response. Shouldn't we instead state that headers
> sent with interim responses will not affect the final response and may be
> ignored by a number of intermediaries or UAs ?

That is true, and we could state that.

So Mark -- what made you start this thread? What's the problem you think 
we need to fix?
Received on Wednesday, 6 July 2011 08:31:27 UTC

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