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

In message <0356EBBE092D394F9291DA01E8D28EC201186DF063@sem002pd.sg.iaea.org>, K
.Morgan@iaea.org writes:
>On Sunday,22 June 2014 14:36, phk@phk.freebsd.dk wrote:

>>>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.

Yes, the length-extension would be available on all frames, which is why
we need a SETTING to limit what we'll accept in that respect.

For huge file transfers the 16k frames are horribly suboptimal and
having the receiver bang the frame size up once "Content-Length: A_LOT"
has been received will do wonders for performance on both ends.

Obviously, you can also reduce the frame size you'll accept.  16K
is quite large for a number of high traffic sites prone to DoS.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 23 June 2014 10:05:48 UTC