Re: HPACK padding

Another thing would be needing to describe how PADDING and flow control are
related.


On Fri, Feb 7, 2014 at 1:30 PM, Hasan Khalil <mian.hasan.khalil@gmail.com>wrote:

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