Re: WebSockets negotiation over HTTP

On 22/10/2009, at 10:52 AM, Ian Hickson wrote:
>>
>> Until the upgrade is complete, you're speaking HTTP and working with
>> HTTP implementations.
>
> How so? A WebSocket client is always talking Web Socket, even if it
> might
> also sound like HTTP.

Yes, but to someone examining the traffic -- whether in a debugger or
an intermediary -- it looks, smells and quacks like HTTP. It declares
itself to be HTTP/1.1 by using the HTTP/1.1 protocol identifier in the
request-line. What's the point of doing that -- i.e., why not use
WebSockets/1.0?

>> Have you verified that implementations (e.g., Apache module API) will
>> give you byte-level access to what's on the wire in the request, and
>> byte-level control over what goes out in the response?
>
> On the server side, you don't need wire-level control over what's
> coming
> in, only over what's going out.

Yes, you do, because section 5.2 specifies headers as whitespace-
sensitive and header-names as case-sensitive.

> There's already a WebSocket module for Apache, by the way:
>
> http://code.google.com/p/pywebsocket/

Cool.

>> Despite all of this, you say:
>>
>>> The simplest method is to use port 80 to get a direct connection
>>> to a
>>> Web Socket server. Port 80 traffic, however, will often be
>>> intercepted by HTTP proxies, which can lead to the connection
>>> failing
>>> to be established.
>>
>> which I think is misleading; this is far from the simplest way to use
>> WebSockets, from a deployment perspective.
>
> True. I've tried to reword this to avoid this possible ambiguity.

I see those changes in -50; looks good (and a very elegant change).
Thanks.

>> This looks an awful lot like a redirect.
>
> There's no redirection involved here. It's just confirming the
> opened URL,
> as part of the handshake. The TCP connection is not closed (unless the
> handshake fails, and then it's not reopened).
>
>> I see now that you have the client-side fail a connection where the
>> URL
>> doesn't match, but that's really not obvious in 5.1. Please put some
>> context in there and reinforce that the URL has to be the URL of the
>> current script, not just any script.
>
> Ok, I've added a note at the end of that section explaining that the
> user
> agent will fail the connection if the strings don't match what the UA
> sent. Please let me know if you'd like anything else clarified; I
> don't
> really know exactly what should be made clearer.

Did this get into -50? Don't see anything in the diff...

The most effective way of doing this would be to actually define the
new headers' semantics in your draft; Websocket-Location, for example,
is only defined as client-side and server-side behaviours. I know this
is probably intentional, but people will read all sorts of things into
this header (especially since its name is so similar to other HTTP
headers) unless you give some indication of what it means.

--
Mark Nottingham       mnot_at_yahoo-inc.com