Re: Frame Length Restrictions

On 2014–04–17, at 11:24 AM, Jeff Pinner <jpinner@twitter.com> wrote:

> 2) Prevent implementations from sending so much data in a single frame that they cannot respond to incoming re-prioritization information quickly.
> 
> Moving the 16K requirement to the HTTP layer still meets those two goals, and increasing the length frame allows increasing the padding length by a single byte, even if the full 16K is sent in a frame.

Actually, allowing 64K of actual padding does make such head-of-line blocking of a PRIORITY frame possible. There would be no really good reason for it to happen, but an implementation which minimizes the number of padding blocks by maximizing their size is conceivable.

Another way to allow fine-grained padding would be to cap the frame length sans padding at 16K – 7 bytes (16377 bytes). To add a single byte to a full frame, you would remove the 6 bytes of padding and 1 byte of PAD_LOW field, and add an 8-byte empty data frame.

Architecturally, quadrupling the frame capacity to get 7 extra bytes is a little odd. Doubling to 32K would also do the job.

Received on Friday, 18 April 2014 06:55:13 UTC