- 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>
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 UTC