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 17:55:16 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F532AD04-E86B-4005-A2B8-8BA5BA9A146B@gbiv.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
On Jul 17, 2011, at 3:18 PM, Poul-Henning Kamp wrote:

> In message <C6C65DB0-8191-4443-9E9E-C1BBE5166A0E@gbiv.com>, "Roy T. Fielding" w
> rites:
>> On Jul 17, 2011, at 2:15 PM, Poul-Henning Kamp wrote:
>> 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.
> We have three bits of relevant text in 14.42:
> ]   The server
> ]   MUST use the Upgrade header field within a 101 (Switching Protocols)
> ]   response to indicate which protocol(s) are being switched.
> So the server has to send a HTTP reponse with 101 to say that it
> is changing protocol, obviously, this happens before the protocol
> is changed.
> Next:
> ]   The capabilities and nature of the
> ]   application-layer communication after the protocol change is entirely
> ]   dependent upon the new protocol chosen
> Notice:  "after the protocol change"
> ]   [...] although the first action
> ]   after changing the protocol MUST be a response to the initial HTTP
> ]   request containing the Upgrade header field.
> Notice again: "after changing protocol"
> The only way to read these two bits consistently, is to read it as
> 	"a response in the new protocol to the initial HTTP
> 	request which contained the Upgade header field"


> The "final" reponse comes after the protocol switch and the semantics
> of it is "entirely dependent upon the new protocol chosen"

No.  The request was received via HTTP.  It has HTTP semantics.  How the
new protocol acts on HTTP semantics is unknown, but that doesn't change
the fact that the recipient did understand the request and is capable
of responding to the sender of that request according to the semantics
of the received request method.

> There is absolutely no support in the text for the notion that
> the server should send a 200 reponse between the 101 and the
> switch of protocol.

No, there wouldn't be.  The response is in the new protocol format
and we don't even know if that format has status codes.  What we
do know is that the client requested the Upgrade and presumably
knows what to expect in return, whether or not the connection is
upgraded by the recipient.

> ikewise, it is specifically nailed down, that the format of
> (final) reponse to the request comes from the new protocol, in
> whatever shape it feels like.
> Therefore, when upgrading protocols, the 101 is final as far
> as HTTP/1.1 is concerned.

Your logic is flawed.  A protocol is more than just bits on
the wire -- it is also a set of behavioral requirements that are
expected by a client and required of the server (and sometimes
vice versa).  It is an HTTP requirement that, after the 101 is sent,
the server MUST respond to the original request (that contained the
Upgrade header).  The HTTP semantics still govern that request even
after the connection protocol is switched, and therefore the 101 is
not final as far as HTTP/1.1 is concerned.

If an HTTP GET message is received with an Upgrade, then the initial
message sent after the 101 is a response from the server to the
client regarding the final status of that GET.  It doesn't matter
what the new protocol might be -- if it defines Upgrade as a suitable
mechanism for establishing a connection, then it must define a way
to respond to that GET request in the new protocol or it can't be
used.  The client, in turn, will expect the response and the entire
connection will likely be terminated by the client if nothing
is received.  For some methods the response is almost inherent, like
using CONNECT with "Upgrade: TLS" might result in a TLS exchange
that does establish a connection.  For GET, it will be a response as
if the semantic-equivalent of GET were received on a new connection
with that new protocol.

Since the primary design goal of Upgrade was to support HTTPng and
waka (and whatever else like them might come along), the requirement
is very specific and motivated.  This is how we can gradually deploy
a new protocol by offering to upgrade a normal connection on-the-fly
without requiring an extra round-trip.

Received on Monday, 18 July 2011 00:55:47 UTC

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