Re: [hybi] WS framing alternative

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

I'm in general very sympathetic to the WebSocket protocol, because it's 
exactly what we would have needed a year ago in some research we did 
here (using browsers for collaborative editing, coordinated through a 
server).

Also I agree with Ian that for communication between a single server and 
a single client, applications can work out their own "protocol", or some 
classes of applications (e.g. collaborative editing of some type of 
structures) can converge on a "protocol".

As far as the client and the server are concerned, negotiating things 
such as frame length seems rather pointless to me, because: a) we don't 
have any such negotiation currently for e.g. Web pages or images. b) The 
client should know the server reasonably well, and for applications 
where frame length is an issue (e.g. image upload, although I think 
there are way better ways to do image upload than with WebSockets), an 
external description of the service may contain some limits, or the 
"protocol" will say that you have to send the size first and wait for a 
"uploading is okay" from the server.

Where length issues or the like may come into play may be 
intermediaries. And (generic) intermediaries are where metadata is most 
valuable.

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
 >
 >   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.

Regards,   Martin.

On 2009/10/30 6:51, Greg Wilkins wrote:
> Rory Byrne wrote:
>> In a further effort to boost our chances of building robust
>> WebSocket servers, I would hope that we might consider adding some
>> sort of maximum frame length negotiation. Nothing fancy, there
>> could be a suitable default maximum, and a 'Max-Frame-Length' header
>> which enables a client to negotiate a higher maximum. Maybe something
>> like this:
>>
>>          GET /demo HTTP/1.1
>>          Upgrade: WebSocket
>>          Connection: Upgrade
>>          Host: example.com
>>          Origin: http://example.com
>>          WebSocket-Protocol: sample
>>          Max-Frame-Length: 2097152
>>
>>          HTTP/1.1 101 Web Socket Protocol Handshake
>>          Upgrade: WebSocket
>>          Connection: Upgrade
>>          WebSocket-Origin: http://example.com
>>          WebSocket-Location: ws://example.com/demo
>>          WebSocket-Protocol: sample
>>          Max-Frame-Length: 1048576
>>
>> The server would only send a 'Max-Frame-Length' header if it wanted to
>> set the maximum to be lower than the client suggested. Any thoughts?
>
>
> I think having the ability to negotiate such parameters is a good
> way to fail fast if a server and client are not compatible (eg
> client needs to send larger messages than server is willing to
> receive).
>
> But I'm sure that there will be resistance to having such negotiation
> as a mandatory part of the protocol.
>
> However, the problem with making this kind of negotiation optional
> (and this goes for my earlier examples of a load balancer
> communicating SSL info and/or node stickyness), is that the current
> WS protocol has no place for meta data to be added in an optional
> manner - so that it can be ignored by implementations that don't care.
>
> Ian has previously said that instead of adding headers to the
> Upgrade request/response, messages should be injected into the
> stream to communicate this meta data.      However, because
> there is no way to flag these messages as meta data, simple
> implementations are going to try to handle them as messages.
>
> This limitation of no standard meta-data paths, means that it
> is nigh impossible to introduce features like multiplexing,
> load balancing, fragmentations, HTTP transport etc. as optional
> additional specifications built on top of ws.   Because there
> is no meta channel, simple implementations will treat everything
> as a message and break if there is any new protocol layered
> on top.
>
> This is SO simple to fix:
>
>   1) WS should allow arbitrary headers in the upgrade request/response
>
>   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.
>
> With these 2 simple additions, then we could later develop a
> standards that (for example):
>
>   + implement  multi-plexing by negotiated support  in the
>     upgrade request/response and then injecting a meta data
>     packet, before each data packet, containing the information
>     needed to route the subsequent data message.
>
>   + implement standards to send content advisory messages
>     that would contain info such as language, content-type etc
>     for a connection.   These could be used by implementations
>     that wanted to be flexible, or ignored by implementations
>     that are sure they know what they are connecting to.
>
> The current proposal is just too nailed down.  There is no where
> to insert any optional handling.   The API is wired to the TCP/IP
> layer.  The handshake messages are locked down to binary equivalence.
> There are spare framing types available - but any suggestions to
> allocate that space for meta-data have been rejected.
>
> It appears that the whatwg want layered protocols to be controlled by
> the allocation of frame byte values to them and only officially
> sanctified extensions will get the nod.   The Whatwg needs to loosen
> up and realize  that it should not try to completely control how a
> protocol will be used in the wild (eg an not force all servers
> to be 100 line perl scripts).  They have to allow it some room to
> breath and grow.    They need to allocate some space for some
> arbitrary meta data to be used or ignored as implementations see fit.
>
>
> regards
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]