Re: [hybi] WS framing alternative

["Martin J. Dürst" <[e-mail]>]

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:[e-mail]