- From: Osama Mazahir <OSAMAM@microsoft.com>
- Date: Fri, 7 Feb 2014 20:05:07 +0000
- To: 'Martin Thomson' <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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é. > > > >
Received on Friday, 7 February 2014 20:05:37 UTC