#540 jumbo frame, was: Stuck in a train -- reading HTTP/2 draft.

Added this as issue #540: https://github.com/http2/http2-spec/issues/540


-keith

On Monday,23 June 2014 17:55, jasnell@gmail.com wrote:
+1... especially if it means getting rid of CONTINUATION.

On Mon, Jun 23, 2014 at 5:36 AM, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> On 23/06/2014, K.Morgan@iaea.org <K.Morgan@iaea.org> wrote:
>> On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote:
>>> , Matthew Kerwin writes:
>>>
>>>>I realise I should probably clarify my thoughts on what to do if a
>>>>single header doesn't fit in a 16K frame.  The option I like best
>>>>comes from one of PHK's earlier posts, where one of the reserved
>>>>bits in the frame header is used as a "jumbo frame" marker such that
>>>>if it's set the first, say, four octets of payload space is actually
>>>>an extra 32 bits of payload length
>>>
>>> I would have it be the max length of *any* frame we're willing to
>>> accept, and the default would then obviously be the 16kbyte
>>> currently implicit in the standard.
>>>
>>
>> So are you proposing the "jumbo frame" marker for all frames, not
>> just the HEADERS frames?
>
> I suppose so. It makes no sense on a fixed-length frame like PING, but
> it simplifies the machinery no end if all frames have the same
> handling -- that's the whole idea, in fact.
>
>> I think it's a great idea, but I know it makes a bunch of people
>> nervous about HOL blocking if you allow more than 16K in a DATA
>> frame.
>>
>
> Hence the setting.
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/

>

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Tuesday, 24 June 2014 15:51:27 UTC