- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Mon, 24 Feb 2014 08:48:05 +0000
- To: Kazu Yamamoto <kazu@iij.ad.jp>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 24 February 2014 02:53, Kazu Yamamoto <kazu@iij.ad.jp> wrote: > So, the compression ratio is offset by the padding. Do I understand > correctly? Or am I missing something? My understanding is that you pad any HEADERS or CONTINUATION frame out to some implementation-defined size, preventing an attacker from telling how large the compressed header block actually is. For instance, if I chose 100 bytes, I would take any compressed header block and split it into 100 byte chunks, and then pad the last frame out to 100 bytes. Of course, the padding is more flexible than that allowing you to do other things with it. For instance, you could add padding of random size [0, 16kB) to each frame if you wanted to, ensuring that frames vary in size and making it very difficult to determine what exactly is going on. Or, if you want implementation simplicity, you can simply not pad at all. AFAIK the spec only currently mandates that you can _receive_ padded frames: it makes no requirement of you that you _send_ padded frames.
Received on Monday, 24 February 2014 08:48:32 UTC