Subject: Re: [hybi] WebSockets negotiation over HTTP

From: Ian Hickson <[email-masked]>
Date: Fri, 23 Oct 2009 03:48:11 +0000 (UTC)

(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.   `._.-(,_..'--(,_..'`-.;.'

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Oct 2009 09:52:01 +0200

Ian Hickson wrote:
> ...
> ...

Actually, posting is suspended in the two weeks *before* the meeting, 
not during the meeting.

And yes, you can make as much progress as you want (by updating your own 
copy), but the idea is that people *attending* the meeting should be 
able to rely on a stable snapshot for preparation. (BOF and WG 
attendants are supposed to have read the relevant drafts).

So, if there a re pending changes relevant to the BOF, you should submit 
them before Tuesday.

BR, Julian