Re: [hybi] WS ABNF

[Greg Wilkins <[e-mail]>]

Dave Cridland wrote:
> On Mon Feb 15 01:12:53 2010, Thomson, Martin wrote:
>>      frame         = text-frame / binary-frame
>>      binary-frame  = %x80 length *%x00-FF
>>      length        = %x00 / %x01-7f / ( %x81-FF *%x80-FF %x00-7F )
>>
>> This is a canonical length encoding in that it doesn't allow for
>> leading zeroes.
> 
> Am I alone in seeing two design errors here?

Nope - I've been hammering away on these issues for months!

> Firstly, I see no benefit in having two different framing types. I do
> see a marginal benefit in having multiple frame types, but the idea of
> distinct framing just strikes me as a bad idea, and prone to error. I
> think the correct design decision here is that "bytes is bytes", and to
> the wire, all frames are binary and octet counted. I'm not against an
> end marker, incidentally, although I'm not convinced it's needed except
> in early stages of implementation.

I think sentinel marking is not desirable.  We've had enough problems
with protocols being vulnerable to injection attacks without introducing
another.

I think it is crazy to have a protocol where user supplied data can
fool the protocol framing by providing illegal UTF-8.

length based framing is able to efficiently carry all that is required.


> Secondly, is that really a bespoke new method for integer representation
> on the wire? What is the overriding benefit over a network byte order
> 32-bit integer? I see that it can be 1-N octets, and therefore will
> typically save 1-3 octets - I'm assuming we're not expecting to ship
> more than 256M in a frame, where the trade off is.
> 
> But the chances of this making a measurable difference are very slim,
> whereas the perils of decoding a new integer representation seem
> extraordinarily high, especially given that it's a nicely unbounded
> integer. IMAP implementations used to have enough trouble when asked to
> allocate 4G for a literal, after all, but at least I'm unaware of them
> having decoding difficulty. OTOH, with 5 octets, I can now setup a frame
> length of 32G, and I can't see anything suggesting that this is even a
> bad idea, let alone illegal protocol.

+1

> I have other comments - I'm bewildered that a server responding with
> "HTTP/1.1 101 Web Socket Protocol Handshake." will fail to interop with
> compliant clients, for instance - but I'm intending to leave these for a
> later mail - just be warned these are coming.

+100000000000000000000000000000000


cheers