Re: [hybi] Questions and comments on draft-hybi-thewebsocketprotocol-10

[Willy Tarreau <[e-mail]>]

On Mon, Jul 18, 2011 at 05:50:28PM +1000, Greg Wilkins wrote:
> On 18 July 2011 17:06, Mark Nottingham <[e-mail]> wrote:
> > In other words, I'd like to understand things a bit more before making LC comments; there may be good reasons for the few things I saw that raised my eyebrows.
> 
> _this response is non-normative_
> 
> > 1) I missed the end of the handshake saga; can someone speak to why GET was chosen over, say, OPTIONS? Roy seems to have strong feelings about that (see recent discussion on HTTPbis).
> 
> I think we went with GET because Roy was not able to well communicate
> his concerns.   He's done a better job in the recent thread in
> httpbis, and I now understand that he is concerned about the
> outstanding semantic GET.

I would add that there was a GET very early in the specification, when
the protocol was not even HTTP compatible yet. It dates back the era
where it was desirable to use an HTTP-like protocol that was easy to
parse by a simple script. Now we're more in line with HTTP and despite
all the discussions on GET vs OPTIONS, it appeared that there was no
real preference for one vs the other, so it was suggested that this
would not change unless there is a valid reason.

> However I still don't understand why he
> thinks OPTION is any better, as it still is a request that requires a
> semantic response.   In either case I think that websockets should be
> free to define an implicit response (eg 204 No Content) is represented
> by a successful handshake.

Alternatively we could consider that the server's hello is the response
to the request.

> > 2) The Upgrade token has no version; e.g., from the examples in 1.2:
> >    Upgrade: websocket
> > Why? The protocol version seems to be carried in the Sec-WebSocket-Version header; could it not be moved (or copied) to the upgrade token?
> 
> I think we are only just coming around to the acceptance that we
> really do need a version beyond the draft stage.  The version was put
> in a header as it was originally only considered needed to distinguish
> drafts.  If it is going to be there to stay, then perhaps the
> protocol/version format would be better.

I too find it more useful to have the version in the Upgrade header than
anywhere else. For intermediaries it can be very useful to know the version
from the Upgrade header because they can decide what processing to start
depending on what they see there.

Regards,
Willy