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: Wed, 16 Apr 2014 20:24:12 -0700
Message-ID: <CA+pLO_gWE9e5LW=1bRuNhoLgbqeHoGCv+gGidcGW-Qr9UX0iAw@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
One of the requirements for the padding design was to be able to pad the
data by only a single byte. Using a separate padding frame was rejected
because it only allowed padding by a minimum of 8 bytes. Receiving and
trying to pad a full 16K of data with the current spec requires splitting
the frame, which of course requires a minimum of 8 bytes of padding.

We originally dropped the length from 64K to 16K in order to do two things:

1) Increase the likelihood that we force implementations to have to use
continuation frames.
2) Prevent implementations from sending so much data in a single frame that
they cannot respond to incoming re-prioritization information quickly.

Moving the 16K requirement to the HTTP layer still meets those two goals,
and increasing the length frame allows increasing the padding length by a
single byte, even if the full 16K is sent in a frame.


On Wed, Apr 16, 2014 at 6:50 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-04-17, at 8:34 AM, Jeff Pinner <jpinner@twitter.com> wrote:
>
> > With the addition of padding to the framing layer, I believe it is
> preferable to implement the frame length requirement at the HTTP layer to
> allow intermediaries to pad frames without running into frame length
> restrictions.
>
> Is there a particular reason to add back both bits as opposed to just one?
> A 64K frame with 16K of information is quite a lot of padding.
>
> Also, an intermediary can already maximize available padding with a policy
> of preferring to send empty padding frames. There's no limit on the ratio
> of incoming padding to data, so an intermediary which simply preserves
> incoming padding must already be prepared to send anything.
>
> In any case, it sounds like you're solving a specific problem which maybe
> should be mentioned in the RFC. Other than that though, I have no real
> objection... it's a coin-toss issue.
>
>
Received on Thursday, 17 April 2014 03:24:39 UTC

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