W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: #300: Define non-final responses

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 17 Jul 2011 23:39:24 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110717213924.GD31226@1wt.eu>
On Sun, Jul 17, 2011 at 09:15:27PM +0000, Poul-Henning Kamp wrote:
> In message <7D5E6715-1377-45EC-A00E-F3FB6D392AAC@gbiv.com>, "Roy T. Fielding" w
> rites:
> 
> >As mentioned before, that statement is false.  101 is never the final
> >response to the request.  Whether or not a later response is in the same
> >syntax of HTTP is irrelevant to the semantics being described here.
> 
> Actually 101 can be the final response, it all depends on which
> protocol you switch to, and since that is outside the scope of HTTPbis
> there are no absolute answers to this.
> 
> People use UPGRADE to switch to all sorts of protocols, including,
> to my horror, TN3270.
> 
> That is why I wrote that "101 is final as far as HTTP goes."
> 
> What happens next is simply not part of the HTTPbis standard any
> more.

I agree with this statement. The fact that it can be mis-interpreted as
an interim response from an HTTP point of view has already caused some
trouble to get it correctly implemented in intermediaries. Without
explicit processing of 101, an intermediary will get stuck waiting for
the next response which might never come.

Regards,
Willy
Received on Sunday, 17 July 2011 21:39:58 GMT

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