Re: h2 padding

I would prefer adding a (non-compressible?) http header (with a random
data/length string) rather than supporting padding in the framing
layer. This will probably has less overhead, and If the application
has control over the HTTP/2 protocol to the level of specifying
padding, should be also capable of controlling the TLS layer. If the
application does not control TLS, would probably neither control
HTTP/2 details, so better implement the padding as a header, with
regular HTTP semantics.


On Tue, Sep 2, 2014 at 3:38 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> Thanks for the useful information and pointer.  Unfortunately, it seems
> the WG misunderstood the fairly generic advice that was given by the
> Google team.  In particular, where they said "The padding should have
> 1-byte increments" what they meant is that padding should be able to
> expand or reduce by a single byte so that it can mask single byte
> changes to the content (and not look statistically odd).
>
> The right way to do this (if it is done at all in the application layer)
> is to always send the padding frame, for responses from a given resource
> that needs padding for some reason, and only vary the amount of padding
> sent each time (even if it is zero).  Deciding whether or not to write
> the padding frame/length, at run time, would be revealing on its own.
> Hence, the minimum padding under my proposal would be 64bits (the price
> of a padding frame type) but the padding itself is in 1-byte increments
> when compared to other traffic within the needs-to-be-padded space.
>
> That said, I should clarify that I agree with their other advice as well.
> Padding for cryptographic reasons should be handled at other layers.
> However, sometimes it isn't, and in those cases it can only be handled
> where one has control. The extremely rare cases in which we would want
> to do padding in h2 (as opposed to within TLS or within the content)
> are adequately covered by a padding frame, which adds no complexity to
> the rest of the protocol.  In contrast, having optional fields at the
> beginning of every Headers, Data, and Push_Promise frame is adding
> complexity on every single interaction via h2, even if those fields
> are never used in practice.  I think that's a bad trade-off.
>
> ....Roy
>



-- 
Guille -ℬḭṩḩø- <bishillo@gmail.com>
:wq

Received on Wednesday, 3 September 2014 16:41:52 UTC