Re: Hello from Mozilla

On Thu, 16 Jul 2009 00:07:09 +0000 (UTC), Ian Hickson <ian_at_hixie.ch> wrote:
> On Wed, 15 Jul 2009, Alex Rousskov wrote:
>> >>
>> >> 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.
>
> We actually used to do that, but we got requests to make it more
> compatible with the HTTP Upgrade mechanism so that people could add the
> support to their HTTP servers instead of having to put code in front of
> their servers.

Well if those people are willing to re-write their web servers for this
they should be able to re-write them to do the TCP switching itself on
receipt of the first packets, rather than after screwing up the entire
process.

You already specify that receiving N bytes with layout ABC followed by DEF
means the entire stream is WebSockets and verify it. Simply specify it such
that there is no resemblance to HTTP. The compatible servers will handle
it. Intermediaries will see non-HTTP and handle it properly, non-compliant
servers will terminate the WebSockets connection properly.
We already routinely do this in proxies for P2P and other traffic forms.
The only reason WebSockets is having trouble is because it's using a valid
HTTP format.

>
>> >> 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.
>
> Well, since Upgrade is a by-hop packet, apparently that's a moot point
> anyway, because man-in-the-middle proxies will always break it if they're

> present. So I'm not convinced that allowing HTTP modifications matters.
>

The key word there is **always**. Which is not true.

There are many administrators who go out of their way for truely semantic
transparency. They will preserve the handshake. The proxy will appear to be
a valid WebSockets server, handshake, then break on the non-HTTP data of
following requests.

> But the point is that it is a recognisable handshake and so could be
> implemented as a switch before hitting the HTTP server, or it could be
> implemented in the HTTP server itself (as some people apparently want).
It
> fails with man-in-the-middle proxies, but then that's what the TLS-over-
> port-443 solution is intended for.

The first entire year I was with the Squid project was spent emailing
people repeating over and over: "Squid is an HTTP proxy it does NOT proxy
protocol X" and this was for FTP/SMTP/RTSP which only roughly resemble HTTP
in the header layout. The currently spec'd WebSockets handshake will fool
even more people since it looks for all intents and purposed _exactly_ like
an HTTP request. Right down to the HTTP/1.1 reserved protocol label (do get
that changed please).

Amos
Received on Thu Jul 16 2009 - 01:22:34 MDT