Re: Frame Length Restrictions

A few comments below:


On Mon, Apr 21, 2014 at 11:55 AM, Johnny Graettinger <
jgraettinger@chromium.org> wrote:

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

Padding as a security mechanism is not designed with the intent of
minimizing frame size, but rather increasing it to obscure the true size of
the data. Nor is it intended to be simple to proxy (for example, adding or
removing padding affects stream flow control and thus back-pressure across
proxies, even though it has nothing to do with the size of the resources
allocated to a stream).

In particular, attempting to add padding without revealing information is
also not trivial.

In the current implementation, an intermediary that attempts to add padding
to a data frame cannot pad a 16K frame using less than 8 bytes of padding.
If adding a minimum of 8 bytes of padding is acceptable, there we can get
away with using a PADDING frame and removing per-frame padding entirely,
greatly simplifying the spec. If it is not acceptable, then we need to
either make frames bigger or make the allowable application data smaller.



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

We have a small frame size in an attempted to protected against
non-adoption due to anticipated performance/correctness problems with
yet-to-be-written implementations.

For example, the small data frame size was an attempt to prevent
implementations from feeling "non-responsive" to changes in priority and
thus prevent people from adopting HTTP/2 because it felt slower. There is
nothing in the protocol, however, that prevents sending 8k or less data
frames, just as there is nothing in HTTP/1.1 that prevents sending small
chunk sizes. In fact, if the HTTP/2 connection is only used to transfer a
single resource, the additional overhead of small data frames is completely
unnecessary.

Similarly, the small header block size was chosen to make sure
implementations exercised continuation frames so that they would detect
implementations bugs early.

A small frame size is not however a prerequisite to, nor necessarily a
hinderance of, adoption. SPDY has a 16MB frame size for example.



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