On 16/07/2009, at 12:28 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Mark Nottingham wrote:
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.
We don't want to ever have a spec-mandated switch from port to port
(since
that implies an origin change),
Ah - that makes sense.
but basically, that's what the spec
currently says, except it requires the script to detect the failure
at #2
and requires the script to explicitly try again on port 443. (And
except
that the Upgrade has to be precisely constrained, not arbitrary
HTTP, so
that we never get to a situation where the client thinks it has done
an
upgrade but really the other side was tricked into sending the right
bytes
for that, letting the script speak to a poor unsuspecting server that
didn't intentionally opt in.)
So, to be clear, the only time the byte-for-byte HTTP handshake is
used is when it's over a TLS tunnel via CONNECT (i.e., it's not used
to set up the tunnel, but only once it's established)?
If that's the case, should be no problem. A bit weird, thought;
speaking two protocols on the same port isn't really good practice...
Cheers,
--
Mark Nottingham m...@yahoo-inc.com
