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

Re: Frame Length Restrictions

From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 21 Apr 2014 17:03:34 -0400
Message-ID: <CAOdDvNqwY6sneu+7Ko5AEBeTYTJ2s0G91uM88JGhsXRnvqt3=Q@mail.gmail.com>
To: Jeff Pinner <jpinner@twitter.com>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, Martin Thomson <martin.thomson@gmail.com>, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Apr 21, 2014 at 4:20 PM, Jeff Pinner <jpinner@twitter.com> wrote:

>
>
> A small frame size is not however a prerequisite to, nor necessarily a
> hinderance of, adoption. SPDY has a 16MB frame size for example.
>
>
Even though I'm not opposed to your change, I think you're mis representing
the genesis of the 14 bit data length.

The smaller frame size requirement comes directly from experience with SPDY
that shows implementations using content length as frame size for
convenience and then having quality of implementation issues around
priority. (at one point I tested 4 in a row that all did that.) So that's
not speculative.

Of course they could and should use smaller values, but the protocol is
stronger if it leads them to do the right thing automatically. That's the
reason for the change - I thought it should be smaller than 16KB myself but
that's where we ended up.

Your change leaves the 14 bit length restriction in place for http data, it
just opens the door for it to be obviated by padding. I'm not worried about
that, it would take a deliberate design to do that and there are plenty of
other ways to deliberately not honor priority if that's what you're trying
to do :) We still steer implementers in the right direction.

[for clarity I would tweak your change to call out the 14 bit restriction
more strongly inline than just "see xref"]

-P
Received on Monday, 21 April 2014 21:04:06 UTC

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