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 07:14:40 +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: <20110706051440.GA19665@1wt.eu>
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.

I remember in early versions of haproxy when I didn't even know about
1xx responses. Haproxy is able to add a set-cookie header in responses
to perform cookie-based persistence. A customer reported that it failed
on one of their service, where I noticed a lot of 100 responses. The
browsers didn't learn the cookie on the 100 so my set-cookie was ignored.
Fortunately, two weeks ago I had discovered the 100 status and already
had a fix for that. But this is an example of how headers on 1xx might
be ignored or at least not be considered as one would think they should
be.

Regards,
Willy
Received on Wednesday, 6 July 2011 05:15:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:44 GMT