On Feb 1, 2010, at 7:38 PM, Greg Wilkins wrote: > Ian, > > you are not listening to the server side developers. It looks to me like Ian just made a bunch of changes to the draft in response to comments from server side developers. On top of the fact that the WebSocket protocol was essentially designed by server-side developers. Could we please stick to substantive points instead of debating who is listening to whom? > > Apache is telling you that they can't share port 80 Did anyone really say that? Isn't mod_pywebsocket a proof that it is in fact possible: <http://code.google.com/p/pywebsocket/>? > with websocket and you're giving them nothing back! > > For many of us, we are already "near the HTTP spec" and > it's full rules and we've already dealt with the complications. > It is your attempt to simplify HTTP that is causing the > complications. > > We've already parsed the HTTP request by the time that > we know it is a websocket upgrade. We're deep inside > our containers... potentially not even on the same > machine that terminated the HTTP request. As far as I can tell, the WebSocket spec does not require special hardcoded handling of the request handshake. It's totally allowed to run it through a normal HTTP stack. In fact, it's totally allowed for servers to do no checking of the client request handshake at all, but that creates a security hole (possibility of violating integrity of a WebSocket service with XDomainRequest, cross-site XHR or cross-site form submission), one of the security holes we are trying to fix. > > Nobody is saying that a compliant websocket server has > to also be a fully compliant HTTP server. > > We are simply saying don't impose additional constraints > on the format of the HTTP request/response. Allow > them to be order and case insensitive and you're more > or less done. FWIW I think my nonce proposal would allow doing this for the response at no cost in security - getting your victim to echo back a hash of an unpredictable nonce is so unlikely that there's no need to count on newlines in the handshake. I wish you could consider the nonce handshake proposal and report whether it addresses your concerns. Instead, you are just repeating your own suggestion. I listened to you and gave you feedback. I even made a proposal that tries to address the requirements you have identified. Can you please do me the same courtesy? Would it be helpful if I spelled out the nonce proposal in more detail and explained how it fixes security vulnerabilities in the current handshake, while also making it easier to integrate with existing servers? I admit both my explanation and Ian's later summary were somewhat roughly sketched out. Regards, Maciej
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.