RE: HPACK padding

As previously discussed, padding granularity should be at the byte level,
with a minimum nonzero pad amount of one byte. If we simply have a PADDING
frame, the minimum nonzero pad amount is eight bytes.

On Fri Feb 07 2014 at 3:09:11 PM, Osama Mazahir <OSAMAM@microsoft.com>
wrote:

> Wouldn't it be easier just to have a separate PADDING frame instead of
> having flags, and associated logic, in HEADERS, CONTINUATION and DATA
> frames?
>
> The objective is not to obfuscate the frames, but to allow varying the
> resultant ciphertext size.
>
> It seems easier to code such that you construct your frames normally as is
> today.  And then append a discrete PADDING frame, if desired.  And then go
> through the standard TLS code.  On the final receiver, you just add a
> switch-case for the PADDING frame type and drop it on the floor.
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Friday, February 7, 2014 9:43 AM
> To: RUELLAN Herve
> Cc: ietf-http-wg@w3.org
> Subject: Re: HPACK padding
>
> I'm going to do this.  If I hear screams, I have the power to back out the
> relevant commits.
>
> On 7 February 2014 07:43, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
> wrote:
> > For solving issue #346, HPACK padding, Roberto proposed to extend the
> padding mechanism for DATA frames to HEADER and CONTINUATION frames.
> >
> > I think that makes sense : we have only one padding mechanism. As such,
> we have one central location for deciding whether padding is necessary in
> regards of all the available information.
> >
> > Any though?
> >
> > Hervé.
> >
> >
> >
> >
>
>