On Tue, 2 Feb 2010, Greg Wilkins wrote: > > I think you've left out the main suggestion that's been made on this > list. > > Leave the handshake more or less as it is, but specify it as a real HTTP > request and real HTTP response, rather than a binary almost-equivalent. That's basically a non-starter, IMHO. The HTTP rules are orders of magnitude more complicated than necessary here. Given the goal of making this trivially implementable, we can't require that servers implement every last detail of the HTTP rules. > The immediate benefits of this change are: > > + that it allows the handshake to work with existing HTTP servers and > intermediaries. > > + No need to explicitly specify behaviour such as HttpOnly cookies. > that behaviour is inherited from the HTTP specs. > > + If HTTP/1.2 or HTTP/2.0 ever come out, then websocket will > continue to work with new servers as the binary response > line will not need to be changed. We can handle all three of these points without going anywhere _near_ the full HTTP rules with all their complications. > It would allow some simple extensions. Extensions should be done by changes to the spec, no need for the whole HTTP ruleset. Even with the current strict rules it's easy to extend the spec in the future. > For example redirection could be supported with a 302 response. For > example is the server responded with > > HTTP/1.1 302 Found > Location: ws://foo.com:81 The spec actually has redirect support already, but it is commented out because it introduces a number of security problems. In practice it's unnecessary; just do the redirect at the subprotocol level if you need it. > then the ws client could open port 81 and immediately start talking > websocket without any handshake at all (because of the ws://). That would be a pretty big security hole! -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.