Hello Ian, [order of citations somewhat rearranged.] On 2009/10/30 13:22, Ian Hickson wrote:
On Fri, 30 Oct 2009, "Martin J. Dürst" wrote:That said, however, I also agree with some other people on this list that extension points should be considered carefully. Greg's proposal:1) WS should allow arbitrary headers in the upgrade request/response
>On Fri, 30 Oct 2009, Jamie Lokier wrote: >> Since you must negotiate any custom protocol layered on top of >> WebSocket out of band anyway (e.g. by agreeing what is present on some >> URL) >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?
2) WS should define a frame type for transport meta data, whose content is defined only as Mime (or just mime headers). The semantics of these can be left to other protocols built on top of WS.seems to be a very good starting point.Could you elaborate on what problem this solves?
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. In that case, you are fine. 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.
Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.