W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Header Size? Was: Our Schedule

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 28 May 2014 17:29:28 -0700
Message-ID: <CAP+FsNf-Pv1NbU4axWgvJNLpFXPWtD7v3Z=W8g+=Lg5bQoowTg@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: "Richard Wheeldon, (rwheeldo)" <rwheeldo@cisco.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
...And we chose one size limit for everything, which included headers
frames.
On May 28, 2014 5:28 PM, grmocg@gmail.com wrote:

> No it was reduced to ensure that people mux with small enough segments
> that the priority inversion delay that occurs when higher priority data is
> blocked behind lower priority data is small enough that the protocol works
> properly.
>
> That it helps to prevent the backup generator problem is icing.
> On May 28, 2014 5:02 PM, "David Krauss" <potswa@gmail.com> wrote:
>
>>
>> On 2014–05–29, at 1:23 AM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>> > On 28 May 2014 08:51, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com>
>> wrote:
>> >> The following are based off yesterday's CWS traffic. ~ 6BN requests of
>> which only 123 fall into the > 64K category. So, yes they exist but they're
>> a tiny edge case.
>> >> Header sizes in each case are rounded down to the nearest KB.
>> >
>> > Awesome, thanks!  If we are interested in discussing who to throw off
>> > the bus, 64K seems like good break point to discuss.  Though that
>> > doesn't avoid the need for continuations entirely.
>>
>> It does if the max frame size goes back up to 64K. It was only reduced to
>> artificially make continuations more likely, right?
>>
>> As for common-case head of queue blocking, DATA frame payloads can still
>> be limited to 16K if we like. Such a limit disparity also solves the
>> padding granularity problem.
>>
>> Again I’ll suggest that nobody gets “thrown off the bus” if the canonical
>> translation to and from HTTP/1.1 uses an initial sequence of header blocks,
>> with routing information going into the first block.
>>
>>
>>
Received on Thursday, 29 May 2014 00:29:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC