Re: #540: "jumbo" frames

On 11/07/2014 11:39 a.m., Nicholas Hurley wrote:
> Which is why we should make sure that there are extensions that people want
> to use, as soon as the spec is ready. I see no reason why exceedingly large
> frames (along with altsvc, which I *definitely* want) can't be among that
> list.
> 

There are a number of small problems to doing this as an extension. All
of which incrementally add up to the big problem of processing latency.


Making fields to hold non-16bit length values an optional field:

 Adds processing latency looking up two locations for the length value.

 Adds confusion over the meaning of any non-zero value stored in the
"normal" length field. Reintroducing potential for smuggling attacks
which HTTP/2 frame length was supposed to kill off.

 Adds ambiguity into where it is located in relation to all other
extensions optional fields. Because more than one extension may require
their optional field to be "first" after the default frame header all
such optional fields will require a type encoding prefix. Making it
bigger than necessary to hold just the length, and adding processing
latency to both find and verify.


We have large frames proposal to resolve all of these issues. Like Greg
said in the initial rationale of that thread. The proposed mechanism was
selected for its simplicity in resolving the issues at hand in threads
like this old one.

Amos

Received on Friday, 11 July 2014 09:45:24 UTC