On Fri, 30 Oct 2009, "Martin J. Dürst" wrote: > > > >Actually the WebSocket-Protocol header lets you negotiate that at > >connection time. > > Does that mean that WS allows arbitrary headers in the upgrade > request/response? Or that there is one header, WebSocket-Protocol, with > potentially a lot of data stuffed into it? You can set the desired value for -Protocol header by passing a parameter to the WebSocket constructor. That sets the value from the client. The server then responds with the protocol _it_ supports. If the two match, the client provides the connection to the script. To support multiple protocols, the server can use the client-provided value to decide which one to use. > You seem to assume that Web Sockets communication is basically just > between a client and a server, without any intermediaries getting > involved in any significant way. Without any independent intermediaries, anyway. On the server side, there can be whatever intermediaries the server-side developer likes; they can all be considered to be the server-side implementation from the perspective of the client (and the spec). > But if there's anything where intermediaries get involved in a specific > way (other than just letting everything through or just blocking), then > there's probably a need to let these intermediaries know some info. > Because the payload frames are for data exchange between the client and > the server, they are essentially opaque to intermediaries, so you can't > use them for that purpose. That's where a separate frame type comes in > handy. What's the use case for independent intermediaries? -- 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.