Re: 1xx response semantics

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 ?

Willy

Received on Wednesday, 6 July 2011 08:29:04 UTC