Re: Hello from Mozilla

I missed that Ian was still talking about using port 80. I think
that's broken / more trouble than it's worth, for the reasons Adri is
going through.

If you have to tunnel using an existing port, use 443 (with null
encryption if you're worried about overhead, but still want to
authenticate the endpoint). Even then, Wifi hotspots are probably
going to redirect you, but using 443 should be a last-gasp measure
anyway.

Cheers,

On 17/07/2009, at 3:18 PM, Adrian Chadd wrote:

> 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

--
Mark Nottingham       mnot_at_yahoo-inc.com