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