Re: Hello from Mozilla

tor 2009-07-16 klockan 23:53 +0000 skrev Ian Hickson:

> 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.

I don't buy this. If the user has such control over the server then it
doesn't matter how precisely you define the protocol handshake octets.

Opting in to an HTTP Upgrade requires sending an 101 HTTP response back,
which is not an easy task to do to unsuspecting servers...

> 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.

And I fully agree here.

> 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.

Sure. And what they will be implementing won't be what you have
specified as their servers will process the HTTP request.

Additionally clients won't implement what you have specified either as
there will be users of this "over HTTP" mechanism which demands more
things like support for NTLM or Digest authentication, or even
authentication challenges in general before accepting the Upgrade.

> 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.

Correct. You don't need to care about intercepting proxies, other
perhaps to note that those as deployed today will often break HTTP
Upgrade.

Our concerns here is that the way you have specified the protocol will
cause it to break in many perfectly valid HTTP server setups, or require
very special support in the infrastructure to avoid breakage going
beyond what is required for supporting HTTP Upgrade.

Regards
Henrik
Received on Fri Jul 17 2009 - 02:32:09 MDT