Re: [hybi] WS ABNF

[Jamie Lokier <[e-mail]>]

Dave Cridland wrote:
> >It's not really new; something similar (or even the same thing?) is  
> >used in HTTP chunked encoding.
> 
> Chunked uses a (straightforward, if excitingly unique) ASCII hex  
> representation of the size of the following chunk, and chunked  
> terminates with an empty chunk (and the trailer).

One crucial difference with chunked is, if you think the recipient
will break with a chunk >=2GB (say), you can arbitrarily limit the
maximum chunk size by introducing splits.

But of you actually have an 8GB WebSocket message, a 32-bit length
would introduce an arbitrary limit guaranteed to break.

I know that's not intended normal WebSocket usage.

But imagine someone writes a trivial WebSocket services which recieves
the name of a file (say, it's just an example), and sends back the
contents of the file as a message.  Imagine it was written intended
for small files, but someone decided to use it for bigger ones one day
because it was convenient to do so, and it turned out to work fine.

Then one day, someone else puts an 8GB file there and expects it to
work.  Why should it be fine for 3GB files but fail for an 8GB file?

> It's passingly similar to UTF-8 codepoints, I suppose, and something  
> about it nags me into thinking of BER, and the self-termination is  
> vaguely reminiscent of the encoding used for codepoints in punycode,  
> albeit not nearly as clever.

Maybe for generality (no fixed limit), but it might have been an
attempt to use fewer bytes for small messages.  Considering most
messages are expected to be small(*), that's not entirely illogical.

(*) - The WebSocket JavaScript API philosophy pretty much requires this,
although other clients aren't bound in the same way.

-- Jamie