On Wed, 28 Oct 2009, Greg Wilkins wrote: > > > > For the packet-forwarding ones, are we talking about inserting a > > header on incoming connections (client to server) or outgoing > > responses (server back to client)? > > Again - there are a huge number of variations. > > But inserting X-forwarded-for headers on requests and Via headers on > responses is common. So is setting cookies on responses so that > subsequent connections can be balanced the same. Also SSL offload will > want to set certificate details in the request header. It sounds like there are some intermediaries that are harmless and would work fine, and others that are harmful and which WebSocket would correctly detect and prevent connections through. If someone wants to deploy a WebSocket server behind the latter, they'll quickly discover the problem, so it doesn't seem like it'd be a barrier to adoption. It's client-side intermediaries that are the main concern (and for which TLS-based WebSocket is the most obvious solution in most cases). -- 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.