Re: Frame Length Restrictions

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.)
>
>