RE: Stuck in a train -- reading HTTP/2 draft.

On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote:
> In message <CACweHNBNUpPWLw+NOE0s17LWL_1OKjWDitTGMxtaUUw6+=UqJg@mail.gmail.com>
> , 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 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.

But, to quote Roy from an earlier thread ...

On Tuesday,22 April 2014 09:00, fielding@gbiv.com wrote:
> Likewise, restricting packet sizes to a small length in order to prevent fools from HOL blocking
> their own multiplexed channels makes some sense, for browser developers.
> However, it actively harms applications of HTTP that are not interested in multiplexing
> because they only want to transmit a single large data stream.
> ... I don't think it makes sense to limit an application-level protocol to the worst case.
> ....Roy

I completely agree.

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 Monday, 23 June 2014 09:54:17 UTC