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 mnot_at_yahoo-inc.comReceived on Thu Jul 16 2009 - 02:52:41 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 12:00:05 MDT