2009/7/16 Ian Hickson <[email protected]>: > 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.
Right. So why not extend the spec a little more to make a tunneling based upgrade process or something over HTTP? 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. This includes things like authentication, which I believe Henrik mentioned. > 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. 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? > 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. 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. The point is, there may be a whole lot of stuff going on with HTTP implementations that you're not aware of. I'd rather invest my time in making certain that what you speak on port 80 is -still HTTP- (and what you speak to proxies which are relaying your websocket data around is also HTTP) right until a well understood protocol upgrade occurs. Frankly, I'm curious how the process got this far inside the websockets community -without-having -anyone- with HTTP experience step up and state all the reasons this is a bad, bad idea. Surely mozilla has some smart HTTP clued up people on board? :) Adrian
