Re: Hello from Mozilla

2009/7/17 Ian Hickson <ian_at_hixie.ch>:

>> That way you are still speaking HTTP right until the "protocol change"
>> occurs, so any and all HTTP compatible changes in the path(s) will
>> occur.
>
> As mentioned earlier, we need the handshake to be very precisely defined
> because otherwise people could trick unsuspecting servers into opting in,
> or rather appearing to opt in, and could then send all kinds of commands
> down to those servers.

Would you please provide an example of where an unsuspecting server is
tricked into doing something?

>> Ian, don't you see and understand the semantic difference between
>> "speaking HTTP" and "speaking a magic bytecode that is intended to look
>> HTTP-enough to fool a bunch of things until the upgrade process occurs"
>> ? Don't you understand that the possible set of things that can go wrong
>> here is quite unbounded ? Don't you understand the whole reason for
>> "known ports" and protocol descriptions in the first place?
>
> Apparently not.

Ok. Look at this.

The byte sequence "GET / HTTP/1.0\r\nHost: foo\r\nConnection:
close\r\n\r\n" is not byte equivalent to the sequence "GET /
HTTP/1.0\r\nConnection: close\r\nHost: foo\r\n\r\n"

The same byte sequence interpreted as a HTTP protocol exchange is equivalent.

There's a mostly-expected understanding that what happens over port 80
is HTTP. The few cases where that has broken (specifically Shoutcast,
but I do see other crap on port 80 from time to time..) has been by
people who have implemented a mostly HTTP looking protocol, tested
that it mostly works via a few gateways/firewalls/proxies, and then
deployed it.

>> My suggestion is to completely toss the whole "pretend to be HTTP" thing
>> out of the window and look at extending or adding a new HTTP mechanism
>> for negotiating proper tunneling on port 80. If this involves making
>> CONNECT work on port 80 then so be it.
>
> Redesigning HTTP is really much more work than I intend to take on here.
> HTTP already has an Upgrade mechanism, reusing it seems the right thing to
> do.

What you intend to take on here and what should be taken on here is
very relevant.
You're intending to do stuff over tcp/80 which looks like HTTP but
isn't HTTP. Everyone who implements anything HTTP gateway related (be
it a transparent proxy, a firewall, a HTTP "router", etc) suddenly may
have to implement your websockets stuff as well. So all of a sudden
your attempt to not extend HTTP ends up extending HTTP.

>> The point is, there may be a whole lot of stuff going on with HTTP
>> implementations that you're not aware of.
>
> Sure, but with the except of man-in-the-middle proxies, this isn't a big
> deal -- the people implementing the server side are in control of what the
> HTTP implementation is doing.

That may be your understanding of how the world works, but out here in
the rest of the world, the people who deploy the edge and the people
who deploy the core may not be the same people. There may be a dozen
layers of red tape, equipment lifecycle, security features, etc, that
need to be handled before "websockets happy" stuff can be deployed
everywhere it needs to.

Please don't discount man-in-the-middle -anything- as being "easy" to deal with.

> In all cases except a man-in-the-middle proxy, this seems to be what we
> do. I'm not sure how we can do anything in the case of such a proxy, since
> by definition the client doesn't know it is present.

.. so you're still not speaking HTTP?

Ian, are you absolutely certain that everywhere you use "the
internet", there is no "man in the middle" between you and the server
you're speaking to? Haven't you ever worked at any form of corporate
or enterprise environment? What about existing "captive portal"
deployments like wifi hotspots, some of which still use squid-2.5
(eww!) as their http firewall/proxy to control access to the internet?
That stuff is going to need upgrading sure, but I'd rather see the
upgrade happen once to a well thought out and reasonably well designed
protocol, versus having lots of little upgrades need to occur because
your "HTTP but not quite HTTP" exchange on port 80 isn't thought out
enough.

Adrian
Received on Fri Jul 17 2009 - 05:18:14 MDT