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

Re: Frame Length Restrictions

From: Jeff Pinner <jpinner@twitter.com>
Date: Tue, 22 Apr 2014 00:48:37 -0700
Message-ID: <CA+pLO_i3guT+U0SOn7n0zLuSouXLiOAEYRQmSGtyHYAZJzPZVA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, Patrick McManus <mcmanus@ducksong.com>, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Apr 21, 2014 at 9:03 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> Not so.
> Rather than 8 bytes of overhead every 2^14-1 bytes, you have 8 bytes
> of overhead every 2^14-9 (or 8, which is be sufficient).  If that's a
> problem, then any sort of framing overhead is a problem.

I don't think I follow. Are you saying that the overhead of always
splitting frames is negligible so it's ok to always split frames in order
to not have a discontinuity in padding?

That seems to be saying that implementations that don't always split frames
could have an issue but they should just "do the right thing" instead of
forcing it by calling out the restriction in the protocol itself.

If that is the argument (and I'm not saying it is) then it seems antithesis
to restricting the frame length in the first place. Arguably
implementations that care about responsiveness should "do the right thing"
and restrict the data payloads instead of having the protocol force them to
do so at the expense of applications that either do not multiplex or do not
care about interactivity.
Received on Tuesday, 22 April 2014 07:49:04 UTC

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