Re: Hello from Mozilla

On Sat, 18 Jul 2009, Amos Jeffries wrote:
> >
> > But per HTTP specifications such body data is part of the HTTP Upgrade
> > request and should be ignored if switching protocols as part of
> > ignoring the HTTP request which contained the Upgrade request.
> > Consider for example if the request is a POST request, containing a
> > alternative simplex representation of the communication meant to be
> > used by a non-WebSockets server.
>
> Ian: is that a relevant case? you can spec it in or out as needed.
>
> But I'm thinking out, since the idea here is to setup a TCP-link tunnel
> then perform authentication handshake inside it. The upgrade request is
> only to get the MITM/Surrogates to pass it correctly or fail it cleanly.

I'm not sure what you're asking here, sorry.

> > > 3.1.5.4
> > > A server receiving a valid HTTP Upgrade request to WebSockets
> > > and which does not accept that WebSockets upgrade MUST send back
> > > a 4xx or 5xx HTTP response as per section 3.1.5.2.
> >
> > There is no such requirement in HTTP. Handling Upgrade is purely
> > optional and the server is free to ignore Upgrade. Upgrade is a "please
> > upgrade to one of these protocols if supported".
>
> Meaning HTTP does not care what gets returned...
>
> At the non-101 reply point its not usable as a WebSockets link. This bit
> is going slightly beyond HTTP in a compatible way and refers to the
> WebSockets-enabled server rejecting the socket connection.
>
> Ian mentioned many times WebSockets being 'opt-in'. This clause permits
> 'opt-in' to be denied by the server. It's irrelevant to non-WebSocket
> intermediaries and applies only to WebSocket origin servers. Perhapse
> that needs to be worded clearer.

I'm not sure exactly what part isn't clear. If you mean some text in the
Web Socket protocol draft, could you elaborate on what change you are
requesting?

> > > The server SHOULD send only the following lines:
> > >
> > > HTTP/1.1 101 Web Socket Protocol Handshake
> > > Upgrade: WebSocket
> > > Connection: Upgrade
> >
> > While it's true HTTP does not mandate any headers for 1xx responses,
> > including things like Server is a good idea in 101 responses, and
> > there may also be other headers required by the HTTP operation such as
> > Authentication-Info and possibly other headers as well in future
> > specifications.
>
> Ah yes. Okay.
> Ian: anything else you find useful as required here as well. This is where you
> get the "is the mystery server capable of WebSockets" info. Being the _right_
> one needs must separate and handled by the WebSockets handshake.
>
> Just only specify it at the string level. Specifying the order sent is fine
> but confusing because it implies order received. Specifying the order received
> beyond 101 is broken.

I really don't understand what you are asking here. Do you mean that the
handshake should allow the "Upgrade" and "Connection" lines to be sent in
any order?

Surely once the HTTP server has decided that it can Upgrade, it doesn't
actually need to worry about sending back something HTTP-valid at all,
since we can just say the entire connection was always using the WebSocket
protocol, and was never HTTP.

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