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

Re: Making Implicit C-E work.

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 15 May 2014 19:56:22 +1200
Message-ID: <53747326.3020700@treenet.co.nz>
To: ietf-http-wg@w3.org
On 15/05/2014 1:48 p.m., Martin Thomson wrote:
> Yep, it's several orders of magnitude more memory, worst case, than not
> decompressing. Which seems like it might well be the corner case.
> But misbehavior, or simple overloading, have relatively straightforward
> detection and mitigation techniques.  Well behaved clients, which form the
> bulk of everyday requests, should require a minimal commitment to support.
> I doubt that you would have much more than 100k open streams requiring
> decompression, even with a total pool of 10 million connections. A few
> Gbytes is hardly a major capital outlay.
> Maybe I'm completely wrong, and you can prove it, but those numbers just
> don't scare me that much.

That was with 100 streams. The default/minimum in h2.

A typical Squid intermediary already has to expect between 1k and 10k
clients in any given second of the day. (Squid is not exactly known for
its high levels of client capacity).
 Meaning the RAM requirement just jumped up to 40GB of active state.

> I am down with Matthew's suggestion here to lift the MUST. Though I note
> that there are cases where this places an intermediary between a rock and a
> hard place in terms of conflicting requirements. Maybe we can note that an
> intermediary /could/ decompress and leave the normative text out of it.

I am +1 on relaxing the MUST. Although removing the implicit gzip
entirely and making any encoding stay explicit would be better.

Received on Thursday, 15 May 2014 07:56:54 UTC

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