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: Tue, 5 Jul 2011 10:25:21 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, httpbis Group <ietf-http-wg@w3.org>
Message-ID: <20110705082521.GB14842@1wt.eu>
On Tue, Jul 05, 2011 at 09:41:33AM +0200, Julian Reschke wrote:
> On 2011-07-05 01:41, Mark Nottingham wrote:
> >One (of many) of the issues with 1xx responses is that people don't know 
> >how to surface two responses to one request in APIs and tools.
> >
> >I think we could make things a bit easier for folks if we stated that 
> >the headers in a 1xx response are semantically not significant; i.e., 
> >it's OK for APIs, etc. to drop them on the floor, because the only 
> >information is in the status code.
> >
> >This would mean that people shouldn't put headers on a 1xx response and 
> >expect applications to see them -- which I think is already the case 
> >today.
> >
> >Thoughts?
> >...
> 
> This is news to me. Where does the spec say that right now?

Strange, I too was sure it was the case but I failed to find that now.
RFC2616 only said "There are no required headers for this class of
status code."

I wonder whether we would have discussed this in the past concerning the
meaning of headers sent with an interim 1xx response, for the final response.

Maybe we should refine the indications so that it's more clear that any
header may only have a meaning for the progress status and that it must
not affect the final response ?

Willy
Received on Tuesday, 5 July 2011 08:25:48 GMT

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