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 [email protected]
