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

Re: 1xx response semantics

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 6 Jul 2011 10:09:36 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <20110706080936.GA20337@1wt.eu>
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.

Received on Wednesday, 6 July 2011 08:10:08 UTC

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