On Wed, 28 Oct 2009, Greg Wilkins wrote: > Ian Hickson wrote: > > 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). > > But they need to be able to set cookies and headers in order to work. > > Setting these on the upgrade request and response should be perfectly > possible and HTTP legal. It would allow existing intermediaries to > communicate important information to client (which node they are stuck > to) and to server (ssl and original client details). > > These are just a few of many examples of why allowing an intermediary to > add meta data is an important part of a web protocol. > > WS does not allow this because it is trying to do an end-run around > intermediaries rather then trying to sensibly work with them. WebSocket doesn't preclude WebSocket-aware intermediaries inserting data into the stream. It will have no effect, though; a WebSocket client isn't going to change any cookies or change behaviour based on headers set on the handshake. -- 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.