Re: [hybi] WebSocket feedback

[Vladimir Katardjiev <[e-mail]>]

I like this update, especially that the handshake is human-readable in the spec now. Caveat that I haven't implemented it yet so I guess proper feedback comes then.

On 4 mar 2010, at 08.25, Greg Wilkins wrote:
> 
> If the handshake messages are to contain content, then they
> MUST have headers to indicate the content length to be legal
> HTTP: in this case, a Content-Length header would be appropriate

I interpret the "content" to not relate to the HTTP handshake, but belong to the WebSocket stream. To quote:

"I've moved some of the handshake to the WebSocket 
_connection_, after the headers." (emphasis mine)

Besides, a GET request can't have a body, so it's pretty much intended to break. However, if you instead view the sequence as WS Upgrade -> client sent body -> server sent reply it is perfectly valid.

> Considering that we are already shipping products with
> websocket implementations from the existing draft, can we
> specify a transition to the new handshake in an appendix.
> 
> Ie while the standard is under development connections without
> websocket keys MAY be accepted, but implementation SHOULD warn
> that support for such connections is deprecated.

Actually, it's not enough to just drop the keys. The header names changed too so you'd need to read WebSocket-Location instead of Sec-WebSocket-Location, for example. It's almost as if we're at a new "version" now.
> 
> The text of 1.3, still kind of implies that the HTTP fields
> must be ordered as per the spec.  Can we add a sentence to say
> that header ordering may be different.

YMMV, but I don't see any such implication in the text.

Later on, the client handshake is explicitly asked to send the headers in a _random_ order (although _any_ order should do fine?) so there should be no confusion on that point.
> 
> Also I'm not sure this sentence is really that clear:
> 
> "Additional fields are used to select options in the WebSocket
>   protocol.  The only option available in this version is the
>   subprotocol selector, |Sec-WebSocket-Protocol|:"
> 
> I thought we were going to allow arbitrary extra headers,
> but that their interpretation was not defined by the ws spec
> other than the optional Sec-WebSocket-Protocol.    We still
> need to allow headers for cookies, authentication etc.

Yes. Client handshake step 15 explicitly adds those cookies. This part I guess is intended for things that can be modified directly using the API. The "arbitrary" extra headers permitted thus far are only things added by the browser implicitly. 

Vladimir