Ian Hickson wrote: > I'm especially interested in feedback regarding actual effects these > changes would have on concrete deployed softare (like, how much easier > would this make deploying Web Socket on a specific load balancer) and > protocols (like, what actual attacks does this prevent or allow). I think the question of CONNECT vs. Upgrade must come down to: What works over real proxies? CONNECT works over port 443, we know that. We also know it forwards the data in a timely fashion, without depending on the byte values. It is widely used. Upgrade probably hasn't been tested much. It ought to use much the same implementation in a proxy, after the handshake, but you know... I wouldn't count on Upgrade working, without testing it against a wide range of real proxies. Is there any data about this? Are you listening, Google? :-) An interesting idea I've looked at, which would be tricky but _really_ improve widespread support (and compatibility), would be to send something which looks like a valid HTTP long-polling request, and allow the server and any proxies to proactively signal that they'll convert it to the more efficient WebSocket - when they will. When they won't, communication continues over HTTP long-polling, carrying the same messages and subprotocols over that. I guarantee if that could be pulled off, everyone would start using WebSocket asap ;-) -- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.