Subject: [hybi] Question about payload length

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 14:48:03 +0200

Page 17 (draft 10):

   Payload length:  7 bits, 7+16 bits, or 7+64 bits

      The length of the payload data, in bytes: if 0-125, that is the
      payload length.  If 126, the following 2 bytes interpreted as a 16
      bit unsigned integer are the payload length.  If 127, the
      following 8 bytes interpreted as a 64-bit unsigned integer (the
      most significant bit MUST be 0) are the payload length.

What does it mean "the most significant bit MUST be 0"? why?

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 15 Aug 2011 05:56:23 -0700

> What does it mean "the most significant bit MUST be 0"? why?

It means that MSB = 1 is a protocol violation.

I don't know why, but my guess would be: there is no "unsigned long" in Java.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 14:59:36 +0200

> What does it mean "the most significant bit MUST be 0"? why?

Ok, it basically limites the payload size to 2^63 bytes.

Hummmm, 2^63 bytes = 8,5899347e9 Giga Bytes = 8192 Peta Bytes...
And this is the frame size (not the WS message size)... mmm

Why so MUCH???

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 15:00:30 +0200

> I don't know why, but my guess would be: there is no "unsigned long" in Java.

A protocol design based on currently programming languages. Upsss.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 15 Aug 2011 06:06:36 -0700

> And this is the frame size (not the WS message size)... mmm

Why not?

Welcome back to the max. frame size discussion;)

How much is comfortable to you? 1k? 64k?

Is think Greg made that argument: frame size isn't infinite really, it's limited .. yes, to 2^63.

On any account, 2^63 is practically infinite.

On the other hand: it would be trivial to have a "infinite-frame" extension that when
active allows MSB = 1, which would mean: frame length infinite.

That way, you essentially switch back to a non-framed raw TCP (modulo the required
masking from client to server).

WebSockets then is just a fancy prelude to a raw TCP afterwards ..

---

From: John Tamplin <[email-masked]>
Date: Mon, 15 Aug 2011 11:24:59 -0400

> A protocol design based on currently programming languages. Upsss.

The point is what is the value over allowing 2^64 frames rather than 2^63?
 If there is no value, then why do something which is known to complicate
some implementations?  You are likely to wind up with implementations that
use Java long anyway rather than sacrifice performance for the frames that
will actually be sent, which leaves open an attack where some
implementations interpret the frame length differently than other
implementations.

Such cases where different implementations implement slightly different
things have been the cause of many security holes, and are to be avoided.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 16 Aug 2011 02:58:42 +0200

>implementations interpret the frame length differently than other

Implementations that would have no trouble supporting frames larger than
2^63 byte would have to add a check for this error or code to ignore the
most significant bit, which is more complicated than allowing this. And
implementations that have trouble supporting this would have to have the
check (or workarounds) either way (in code it may be for free, but you'd
get more or more complicated instructions either way).

I could not immediately find what implementations are supposed to do if
they encounter frames where the bit in question is set. It's not clear
to me that disallowing such frames is the best way to communicate what
implementations are expected to do with them, even if this is defined in
the specification (some would think, since it's not allowed, they do not
have to worry about the case, for instance).

(I note that more than 2^63 bytes in a frame would amount to something
like downloading all data stored on hard drives in the Netherlands and
would take a year to move through the world's largest exchange point at
peak throughput levels at the moment; it's not reasonable to send this
amount of data, so disallowing sending it would not guide implementers
in what they should put in their code; it's "yeah, whatever".)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/