On Wed, 28 Oct 2009, Greg Wilkins wrote: > Ian Hickson wrote: > > On Tue, 27 Oct 2009, Greg Wilkins wrote: > >> Ian Hickson wrote: > >>> I disagree that the current handshake isn't like HTTP enough, though. > >>> The request is fully HTTP-compliant. What value would there be in > >>> relaxing the rules on what WebSocket clients should send in the > >>> request? I don't understand the real-world case you are concerned > >>> about. > >> What about a load balancer in front of the server that inserts a cookie > >> or X-Forwarded-For header into all HTTP requests that it forwards. > >> > >> This will probably be harmless with regards to the subsequent WS > >> connection, but it will break the handshake so there will not be a > >> subsequent WS connection. > > > > How do such load balancers handle pipelining? > > > > If they support them, then that means they are almost certainly > > incompatible with WebSocket, as far as I can tell, and we would _want_ the > > connection to fail. > > They all are different. But many just look at the first request on > a connection and then just treat the rest of the connection with > packet forwarding. So that type should work. > > Others look at every request and will probably not work. 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)? -- 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.