Re: [hybi] Technical feedback. was: Process!

[Greg Wilkins <[e-mail]>]

Maciej Stachowiak wrote:
> On Jan 29, 2010, at 11:25 PM, Justin Erenkrantz wrote:
> 
>> On Fri, Jan 29, 2010 at 11:13 PM, Greg Wilkins <[e-mail]> wrote:
>>> Note that there are uses for this protocol beyond javascript in browsers. Improvements in the protocol should not have to wait for improvements in just the js API.
>> Agreed - the motivating factors on my end for an async protocol have applications in mind that look nothing like browsers.  (Autonomous agents is probably the shortest
>> description that gets you in the ballpark.)
> 
> The problem here isn't lack of protocol support for binary frames (as far as I can tell), it's the fact that they are unsupported in the proposed WebSocket client API for
> browsers. Am I misunderstanding? I see a full definition of binary protocol frames in <http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68>.
> 
> So, unless I'm misunderstanding, you can send binary frames to your heart's delight if you are not relying on JavaScript code running in a browser. Eventually you'll be able to
> do this from JavaScript too, once we have worked out how to manage binary data.
> 
> The only issue with the protocol here is that there are two kinds of framing. But that's not a limitation on the ability to use binary data in non-browser clients, nor is it a
> cause or effect of limitations in the client API. It seems like a matter of judgment whether it's better to have two kinds of framing are one. The SPDY team concluded that it's
> best for performance to use length-encoded framing for everything, which makes me wonder if that lesson applies to the WebSocket protocol as well.

Correct, we can send binary frames now is we wish and consenting endpoints can handle them.

The issues with this are:

  + Why have two framing techniques when binary is sufficient to carry everything.

  + Who controls allocation of the frame type byte?  So far every suggestion of usage
    for that (eg a bit to indicate that the frame contains meta-data headers) has been
    rejected.   So are binary users simply to pick their own bytes and hope for no
    collisions?   Will IANA eventually allocate values?   is 7 bits enough?

  + Sentinel framing is unsafe.   It relies on the fact that there
    are no 0 bytes in the utf-8 strings that are passed to it.   Strangely enough,
    users can't be trusted to always provide valid utf-8 data, so if user data is
    not validated then sentinel encoding allows frame injection attacks.
    After all we have learnt with HTTP, it seams silly to repeat the mistake
    of a protocol that is exposed to such attacks

  + the utf-8 Sentinel framing is inflexible.  It sends only raw utf-8.
    What if I want to send gzipped utf-8, or utf-16 etc.     This could simply be
    handled with  a content encoding header in the upgrade request and use of
    binary framing.


regards