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

Re: Negotiating compression

From: David Krauss <potswa@gmail.com>
Date: Fri, 30 May 2014 00:36:34 +0800
Cc: Michael Sweet <msweet@apple.com>, Jason Greene <jason.greene@redhat.com>, Martin Thomson <martin.thomson@gmail.com>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D12A74CF-C352-4352-A493-FFEB47AE25DA@gmail.com>
To: Willy Tarreau <w@1wt.eu>

On 2014–05–30, at 12:01 AM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, May 29, 2014 at 11:12:07PM +0800, David Krauss wrote:
>> 
>> There are plenty of other ways for a malicious party to crash a printer. 1.6
>> million instructions is still only a blink of an eye even for a small MCU.
> 
> Well, 1.6M instructions for a request is huge, whatever the processor size.
> That would basically limit a 3 GHz CPU to 2000 requests/s when it can currently
> do 300000 in http/1.1. I'm starting to be really worried…

3 GHz CPUs don’t do only one instruction per cycle. See the caveats I mentioned.

If you want to overwhelm the network hardware in a printer, you can easily do so just given its IP address. Aside from malicious inputs, a printer protocol with so many headers would be simply broken. That is my only point.

Also, the 100 instructions figure is just a guesstimate from looking at my compiled binary. I’ve debugged using only the first example from the spec, but it’s past my bedtime, so maybe someone would like to test further or profile the code. But, again, it is designed for embedded MCUs and not really network-oriented hardware.

https://code.google.com/p/lightweight-http2-huffman-decoder/
Received on Thursday, 29 May 2014 16:37:13 UTC

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