W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

RE: ezflate: proposal to reinstitute deflate header compression

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 3 Jun 2014 08:45:16 +0000
To: Willy Tarreau <w@1wt.eu>, "K.Morgan@iaea.org" <K.Morgan@iaea.org>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "C.Brunhuber@iaea.org" <C.Brunhuber@iaea.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D6215E@ADELE.crf.canon.fr>
> -----Original Message-----
> From: Willy Tarreau [mailto:w@1wt.eu]
> Sent: mardi 3 juin 2014 10:18
> To: K.Morgan@iaea.org
> Cc: ietf-http-wg@w3.org; C.Brunhuber@iaea.org
> Subject: Re: ezflate: proposal to reinstitute deflate header compression
>
> ...
> 
> it yet so I would not pronounce myself on it), but at least it has the merit
> of having been designed for the exact purpose it will be used for. My only
> concern with it is how we could disable it when its gains are not considered
> worth its costs, or when an issue is faced later and we need to disable it.

HPACK in itself can't be disabled, but you can always send headers as literals and flagging them to forbid indexation further down the path. You can do this for all headers, to go back to an encoding close to HTTP/1.x, or only for some critical headers.
This feature was added recently, after a security analysis of HPACK.

> 
> Willy
> 

Hervé.
Received on Tuesday, 3 June 2014 08:46:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC