Re: #300: Define non-final responses

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"

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.

Likewise, 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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Sunday, 17 July 2011 22:18:25 UTC