Re: WebSockets negotiation over HTTP

(cc'ing hybi by request, since this e-mail involves changes to the
WebSocket protocol)

On Thu, 22 Oct 2009, Mark Nottingham wrote:
> 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.

A person looking the traffic in a debugger will clearly see it's
WebSocket, since it says WebSocket at least twice in the request (once on
the second line).

An intermediary is supposed to treat it as HTTP; that is part of how we
get intermediaries to drop the connection (they should fail to recognise
the Upgrade and drop the connection).

> 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?

Wouldn't that be an inappropriate use of port 80?

> > > 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.

You can completely ignore the incoming handshake, actually. Servers aren't
required to do anything with the incoming handshake. There's no big
interop issue with them handling whitespace differently in practice, so
long as the client-side UA follows the spec to the letter.

> > > 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...

Loos like there was some update issue. Try now:

   http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol#section-5.1

You can always find the most up-to-date text on the WHATWG site, if the
IETF update process fails (or when there's an IETF meeting in progress,
since apparently we're not allowed to make progress during IETF meetings):

   http://www.whatwg.org/specs/web-apps/current-work/complete.html#websocket-protocol
 

> 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.

I've tried adding more information to the sections that define headers, to
describe what they do.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'