- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 06 Jul 2011 10:30:55 +0200
- 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