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

Re: #300: Define non-final responses

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sun, 17 Jul 2011 14:39:29 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <C6C65DB0-8191-4443-9E9E-C1BBE5166A0E@gbiv.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
On Jul 17, 2011, at 2:15 PM, 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.

It is part of the HTTP standard, and it is not our problem if some
people who implemented 101 cannot read and obey that standard.

I repeat:  101 is never the final response.  In order for the HTTP
request to be completed, the upgraded protocol MUST respond to the
initial request after the switch is complete.  There are NO EXCEPTIONS.
If the final response is not received, an HTTP error has occurred
even if the connection is no longer being run in HTTP.  What HTTP
does not define is how, not if, that final response is sent.

Received on Sunday, 17 July 2011 21:39:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:58 UTC