Re: [hybi] More feedback on WebSockets

[Greg Wilkins <[e-mail]>]

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.

regards