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:48:36 +0200
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110717214836.GE31226@1wt.eu>
On Sun, Jul 17, 2011 at 02:39:29PM -0700, Roy T. Fielding wrote:
> 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.

Roy, this is not how I read RFC2616 :

  10.1.2 101 Switching Protocols
  The server understands and is willing to comply with the client's request,
  via the Upgrade message header field (section 14.42), for a change in the
  application protocol being used on this connection. The server will switch
  protocols to those defined by the response's Upgrade header field immediately
  after the empty line which terminates the 101 response.

  The protocol SHOULD be switched only when it is advantageous to do so. For
  example, switching to a newer version of HTTP is advantageous over older
  versions, and switching to a real-time, synchronous protocol might be
  advantageous when delivering resources that use such features.

The term "immediately after the empty line which terminates the 101 response"
is pretty clear to me : HTTP ends after the 101 response, and immediately
after it, it is the next protocol. So there clearly is not any other HTTP
response after 101. It may not be how you designed it 12 years ago, but it
is how it's documented and how people have been using it. WebSocket is even
relying on this in the handshake.

Received on Sunday, 17 July 2011 21:49:15 UTC

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