[whatwg] WebSocket framing

Bronislav Klučka Bronislav.Klucka at bauglir.com
Mon Aug 22 00:09:46 PDT 2011

On 21.8.2011 18:44, John Tamplin wrote:
> On Sun, Aug 21, 2011 at 5:05 AM, Bronislav Klučka<
> Bronislav.Klucka at bauglir.com>  wrote:
>> Hello,
>> I'm looking at current WebSocket interface specification
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> complete/network.html#the-**websocket-interface<http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#the-websocket-interface>
>> 1/ and I'm missing the ability to specify, whether data to be sent are
>> final or not (whether the frame to be sent should be continuous or not)
>> I suppose some parameter for specifying final/continuing frame should be
>> there, or some new methods for framing. I've tried to send 100 MiB text from
>> Chrome for testing purposes and since there is no way to specify framing it
>> was send in one piece.  There is no way to stream data from client to
>> server, all data must be kept in memory and sent at once.
> The JS API is entirely at the message level -- the fact that it might be
> fragmented into frames is an implementation detail of the browser and the
> rest of the network.
That was not the point, the point was that current WebSocket JS API does 
not allow streaming of data either from browser or from server (browser 
sends data as one frame, and when receiving exposes to the programmer 
the whole message at once regardless of how server sent the message).  
As persistent and low latency connection, WS would be perfect for 
streaming data. But due to this JS API inability to handle frames, one 
has to implement streaming on server and client all over again even 
though the protocol can be used.
So the point is, couldn't JS API use the ability of the protocol to ease 
streaming implementation?

>> 3/ MessageEvent should expose what kind of data was received, textual, blob
>> or arrayBuffer. This would prevent testing for data type and problems with
>> testing |binaryType<http://dev.w3.org/html5/**websockets/#dom-websocket-*
>> *binarytype<http://dev.w3.org/html5/websockets/#dom-websocket-binarytype>>
>> |property if changed during data receiving.
> At the WebSocket protocol level, there is only text data and byte data.
>   There is no notion of it being sent as a blob or array buffer, and any
> binary data could be received as either, as is convenient to the receiver.
This notice was not about how data are sent, but how data are received.
Regardless of data type the message is received by onmesssage event and 
exposed in data property,
but I guess one can test for data type of this property


More information about the whatwg mailing list