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

Re: Frame Length Restrictions

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Mon, 21 Apr 2014 14:55:14 -0400
Message-ID: <CAEn92TojvQZQM_1vpZpJ_vz++oZFoj-wo_VRF+ZetPGqUeK1=g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
Also, to date HTTP/2 hasn't made it particularly easy for intermediaries to
'forward' frames without deeply understanding stream state. It does seem
odd to make moves in this direction now, and I'd appreciate an explanation
of what this is buying. Eg, unless you're running an intermediary tunneling
1:1 connections, including all settings affecting compression state, you'll
still have to decode & re-compress headers with an entirely different
compression context anyway. Compared to that, the complexity overhead of
re-framing DATA seems pretty small.


On Mon, Apr 21, 2014 at 2:16 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 19 April 2014 15:07, Patrick McManus <mcmanus@ducksong.com> wrote:
> > it only the on-the-wire size that matters.
>
> This is, I think, the reason that this change makes me uncomfortable.
> We have a small frame for a good reason; and allowing padding to
> greater than that size is in direct opposition to that.
>
> (I briefly thought that this proposed change wouldn't cause issues in
> this regard, because the padding could be easily discarded.  But
> that's a great way to negate any benefit gained by padding.)
>
>
Received on Monday, 21 April 2014 18:55:41 UTC

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