Re: Hello from Mozilla

As an alternative, why not:

1) specify a new port for "normal" WebSocket operation, and
2) specify that if there's a proxy configured, ask the proxy to
CONNECT to your new port, and
3) specify that if #2 fails, they can CONNECT to 443 and ask for an
Upgrade to WebSockets in the first HTTP request.

I.e., in the #3 case, they'll be CONNECTing to 443 and asking for a
HTTP connection to 443, and in the first HTTP request (tunneled
through the proxy, so it isn't a hop any more), they'll be asking for
an Upgrade to the WebSockets protocol, which can either succeed or fail.

It works because a HTTP connection inside of a TLS tunnel can't really
have any extra hops (at least, there won't be any outside the control
of the server).

This way, you don't have the brittleness of byte-for-byte (although
once you've upgraded to WS you can specify whatever you like), it
allows "normal" HTTPS-over-443 to work, etc.

They can even do the same handshake over TLS on 443 if they like
(without the proxy).

On 15/07/2009, at 5:59 PM, Ian Hickson wrote:

> On Wed, 15 Jul 2009, Mark Nottingham wrote:
>>
>> Can you remind me why you need the handshake to look like valid HTTP
>> again? I think that's the crux here.
>
> Because in some cases, people will want to share the same port for
> their
> HTTP server as for their WebSocket server. For example, if they want
> to do
> TLS-WebSocket-over-port-443, in the case where that host also has an
> HTTPS
> server on port 443.
>
> --
> Ian Hickson U+1047E )
> \._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _
> \ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--
> (,_..'`-.;.'

--
Mark Nottingham       mnot_at_yahoo-inc.com