Re: #300: Define non-final responses

On Jul 18, 2011, at 1:19 AM, Henrik Frystyk Nielsen wrote:

> For the original discussion for which this thread was started, I completely agree that the initial HTTP request is significant when used with an Upgrade request but once you are outside the HTTP wire-protocol a response can take any number of shapes involving N "successful" messages fulfilling the request where N can be 0, 1, or more. The notion of "successful" is in this context is of course defined by the upgraded protocol.

and the semantics of the request in HTTP.

> I would like to clarify, however, that the initial WebSockets handshake semantically is a GET request and not an OPTIONS request. It has been discussed quite a bit but there are important reasons for why GET is appropriate:
> 
> First, the request URI is used to interact with the WebSockets resource, not the server, and not "about" the resource. That is, the request URI identifies the resource with which you are initiating the WebSockets communication. 

That was not the case the last time I read the spec, but it is good news.

> Second, the initial interaction is a GET in the sense that you do get some representation of the resource you are communicating with. Just like for HTTP itself, the range of how such representations can be manifested is of course very broad but in addition it is not limited to a request/response interaction. At [1] there are several examples of this:
> 
> 1) The stock ticker is an example where the server sends an upgrade GET request where the URI contains a query for the stocks for which ticks are requested. After that the resource simply starts sending back ticks which is very much the representation of that resource.
> 
> 2) The chat example illustrates a case where the chat room is identified by the request URI and the "response" is the state of that chat room.
> 
> 3) The game example provides the state of the game, etc.
> 
> Same thing goes for the other samples. In neither of these cases are there any additional "GET" request defined by the WebSockets communication -- the HTTP upgrade request indeed semantically signifies the interaction with the resource. Once you have established the WebSocket you obviously no longer are bound to a request/response interaction pattern and so can evolve into any message exchange pattern desired but then you clearly are beyond HTTP semantics.

Well, no, we are still bound by the semantics of HTTP.  We are not bound
by the interaction limitations of HTTP, its specific syntax, or even
the nature of its messages.  That's what you mean above, and I agree.

> Third, it is important that the initial handshake is safe and idempotent and entirely described by HTTP; otherwise the scenarios above would all fall apart. As OPTIONS can contain a request entity making it impossible to know what the semantics would be.

The protocol being upgraded to can require that the OPTIONS request be
sent with an empty body merely by refusing to upgrade the connection if
that isn't so.

> All of these in my opinion are consistent with GET and inconsistent with OPTIONS.

Certainly, if the WebSockets server is using the request target to initiate a
response to that HTTP request, then the mechanism of that response doesn't matter.
What matters is that the client doesn't need to repeat its request inside the
WebSockets protocol after the connection is established.  So, if that is true
of the WebSockets handshake, then it is indeed using Upgrade correctly.

Cheers,

....Roy

Received on Monday, 18 July 2011 18:38:39 UTC