[hybi] Websocket feedback was: Addressing Minimal Events

[Greg Wilkins <[e-mail]>]

Jonas, Ian,

just to continue on expanding my feedback on websocket


It would be great if the websocket proposal could include
standard definitions for mime encoded datagrams.

Current frame types are:

   0x00  - sentinel framed UTF-8 message
   0x80  - length framed binary data.

I'd like to see two additional frame types supported
by default:

   0x01  - sentinel framed UTF-8 encoded MIME message
   0x81  - length framed MIME message.


Both these data types would contain a data that commenced
with a standard mime header (RFC 2045).   The header is optional
and terminated by CR LF CR LF.  Thus these types have a minimal
overhead of 4 bytes.

For both these types, any Content-Length header will be
ignored and the length indicated by the websocket framing
minus the header length will be used.

For 0x01 types the content type is assumed to be "text/plain; charset=utf-8"
If a content type header is specified, it must be "text/????; charset=utf-8"

For 0x81 the content type is assumed to be application/octet-stream unless
otherwise indicated.


The websocket API would need to be slightly extended to support some
common types of message.

I would suggest that onmessage always be called for all text
mime types, but with some additional parameters: eg.

   onmessage(text,mimetype,headers)

The browser would be responsible for converting the transported
charset to the charset of javascript. If the conversion could not
be done, then the message would be discarded.

Additional events could be supported if you want the browser/server
to do the parsing for your.   For text/xml & text/html:

   ondocument(dom,headers)

and for text/json

   onobject(object,headers)


To send such messages, the API would also need to support

void postMessage(data,headers);



I think this is a minimal change to websocket and would go a long
way to address many of the concerns raised here.    With the ability
to send standardized meta data, then the job of coming up with
standardized multiplexing is much much simpler.



cheers



Greg Wilkins wrote:
> Jonas Sicking wrote:
> 
>> I believe the latest version can be found at
>> http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol
>>
>> As I understand it feedback is supposed to go to the list we're
>> currently talking on.
> 
> 
> Great!
> 
> 
> Then I reiterate my last feedback - the spec is
> written is a way that is very difficult to understand.
> 
> I'm sorry to be critical of the document - as I know it
> is exceedingly difficult to write good specifications
> that are both understandable and precise, while not
> be too prescriptive of things like ordering and algorithms.
> 
> 
> The spec really needs to have the key concepts described
> in introductory sections rather than by pseudo code
> repeated several times in the body of the document.
> 
> 
> For example, if I want to find out what the frame type byte
> is, I have to go to section 3.2   where I learn that
> it is the first byte read when reading bytes from the
> server.
> 
> But to know what that byte means, I then need to step
> through the pseudo code of what to do if high bit is
> set and then mentally run the iterations in order to
> work out what it means.
> 
> I think have to read the same pseudo code in section 4.2
> to see if the server implements the same state
> machine(s) and thus has the same framing.  I'm still not
> sure if the framing of 3.2 and 4.2 are exactly the
> same?
> 
> 
> It would have been so much simpler just to say:
> 
> 
> 3 Protocol Parameters
> 
>   ...
> 
>   3.x Frame Type
> 
>   The first byte of any websocket message is the frame type,
>   which is used to indicate both the content type and framing
>   of the messasge. Frame types 0x00 to 0x7f (high-order bit clear)
>   represent sentinel framed data. Frame type 0x00 to 0x7f (high-order
>   bit set), represent length encoded framing.
> 
>   3.x.1 Known frame types
> 
>   0x00  sentinel framed UTF-8 data
>    ...   ????
>   0x80  length encoded framed UTF-8 data
> 
> 
> 4 Web Socket Message
> 
>   4.1 Sentinel Framing
>   Blah blah blah 0x00 blah blah blah 0xFF
> 
>   4.2 Length Encoded Framing
>   First bytes represent the message length
>   encoded as a variable length integer.  Each byte contributes
>   7 bits to the length and the first byte with the high-order bit
>   set is the last of the length bytes.
> 
> 
> 
> 
> 
> 
> 
> Another problem is that the handshake is defined by
> explicitly saying what bytes to send: eg:
> 
>    5.   Send the following bytes to the remote side (the server):
>            47 45 54 20
>         Send the /resource name/ value, encoded as US-ASCII.
> 
>         Send the following bytes:
> 
>            20 48 54 54 50 2f 31 2e  31 0d 0a 55 70 67 72 61
>            64 65 3a 20 57 65 62 53  6f 63 6b 65 74 0d 0a 43
>            6f 6e 6e 65 63 74 69 6f  6e 3a 20 55 70 67 72 61
>            64 65 0d 0a
> 
>         NOTE: The string "GET ", the path, " HTTP/1.1", CRLF, the string
>         "Upgrade: WebSocket", CRLF, and the string "Connection:
>          Upgrade", CRLF.
> 
>     6.  Send the following bytes:
>            48 6f 73 74 3a 20
>         Send the /host/ value, encoded as US-ASCII.
> 
>         Send the following bytes:
>            0d 0a
>         NOTE: The string "Host: ", the host, and CRLF.
> 
>    7.   Send the following bytes:
>            4f 72 69 67 69 6e 3a 20
>         Send the /origin/ value, encoded as US-ASCII.
> 
>         NOTE: The /origin/ value is a string that was passed to this 
> algorithm.
> 
>         Send the following bytes:
>            0d 0a
>         NOTE: The string "Origin: ", the origin, and CRLF.
> 
> 
> That's a really long winded way of saying send a HTTP/1.1
> request with some headers set.   More over, that specification
> implies that the order has to be:
> 
>  GET /path HTTP/1.1
>  Upgrade: WebSocket
>  Connection: Upgrade
>  Host: acme.com
>  Origin: origin
> 
> and thus it would be illegal to send:
> 
>  GET /path HTTP/1.1
>  Origin:                origin
>  Host:
>    acme.com:80
>  Upgrade:                 WebSocket
>  Connection:      Upgrade
> 
> 
> This is a perfectly legal HTTP request and should
> be able to be accepted to initialize a websocket
> upgrade.
> 
> 
> 
> 
> regards
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>