Re: Hello from Mozilla

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 15 Jul 2009 17:21:13 -0600

On 07/15/2009 05:00 PM, Ian Hickson wrote:
> On Wed, 15 Jul 2009, Alex Rousskov wrote:
>> On 07/15/2009 01:59 AM, 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.

>> Can such a dual-purpose port-sharing server implement both HTTP and
>> WebSocket stacks and use the right stack depending on the first byte[s]
>> of the incoming message?

> Isn't that exactly what an HTTP Upgrade is?

No, it is not. HTTP Upgrade assumes HTTP traffic first, some other
traffic after the upgrade.

The "TCP switch" scheme sketched above does not have the HTTP traffic
for WebSocket connections and does not have WebSocket traffic for HTTP
connections. There is no HTTP Upgrade involved. Connections start and
finish with only "their" traffic on the wire.

For the TCP switch to make sense, WebSocket handshake must be changed to
remove the HTTP simulation part (with all its negative side-effects), of
course.

>> If port sharing is the primary motivation here, then dual protocol stack
>> support seems like the right solution.
>>
>> This can be even implemented as a dumb TCP-level "switch" application
>> that connects to either an HTTP server or a WebSocket server behind it.
>> No "binary" HTTP messages, no risk of HTTP intermediaries screwing up
>> with the not-really-HTTP-but-looking-like-one traffic. Just two
>> completely different protocols sharing the same port.
>
> That's exactly what WebSocket is doing.

No, it is not. It is pretending to use HTTP before switching to
WebSocket stuff, and it does not allow valid HTTP modifications of the
pretended-HTTP messages.

Hope this clarifies,

Alex.
Received on Wed Jul 15 2009 - 23:21:27 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 12:00:05 MDT