RE: #300: Define non-final responses

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.

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. 

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.

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.

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

I hope this clarified things a bit.

Henrik

[1] http://html5labs.interoperabilitybridges.com/prototypes/websockets/websockets/info

> -----Original Message-----
> From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] On
> Behalf Of Greg Wilkins
> Sent: Sunday, July 17, 2011 23:49
> To: Roy T. Fielding
> Cc: Mark Nottingham; Poul-Henning Kamp; HTTP Working Group
> Subject: Re: #300: Define non-final responses
> 
> On 18 July 2011 11:07, Roy T. Fielding <fielding@gbiv.com> wrote:
> > Other protocols that do not want GET semantics, or some other such
> > semantically significant method, should use something like OPTIONS for
> > the request and specify how to respond to it.  That is what I told the
> > hybi WG.
> 
> Roy,
> 
> Unfortunately your postings to the hybi list did not clearly express
> your concerns with the use of Upgrade.     You have expressed them
> much better here and I finally get it that you are concerned about an
> outstanding semantic request.
> 
> However, I don't understand why an OPTIONS method is any better, as it too is
> a semantic request for information (about the communication
> options available on the request/response chain).   So even after a
> 101, there is a semantic response outstanding.
> 
> So at the very least, protocols like websockets need to deal with the outstanding
> response.  However, as the wire protocol is entirely up to the new protocol,
> surely it is an option for the protocol to use zero
> bytes to "send" and implicit response to the user-agent.      Perhaps
> it would be sufficient for the websockets spec to say that after a successful
> upgrade, the user-agent that issued the upgrade request should receive an
> implicit 204 response.
>

Received on Monday, 18 July 2011 08:20:17 UTC