Re: 1xx response semantics

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

?

Received on Wednesday, 6 July 2011 08:23:45 UTC