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

Re: Negotiating compression

From: David Krauss <potswa@gmail.com>
Date: Thu, 29 May 2014 10:46:17 +0800
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <7B97B7A5-B7E3-4955-B253-F9D070B3A4DD@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>

On 2014–05–29, at 3:18 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On May 28, 2014, at 8:40 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> The DoS surface with HTTP headers is not increased over HTTP/1 (which also would suffer from a requirement to tear down the transport when that kind if thing happens, unlike HTTP2).
>> I believe I've mentioned before seeing rare, but multi-Mb headers in the past. We had, before that experience, amusingly assumed that 16k was enough for anyone, and were wrong by orders of magnitude.
> So I’m wondering. Some of us (not all) seem to be OK with telling some use cases to stick with HTTP/1, like printing or IoT or many of the other places that are outside HTTP/2 “design space”. Why are we going to such lengths to support this abuse of the protocol. Is it just because HTTP/1 allows it?

The Internet Of Things is here to stay, and physically as transistors shrink, microcontrollers and radio sets get smaller and cheaper, and internet connections get more ubiquitous *without* an increase in computing power.

I think this discussion is getting sidetracked, though, because:

1. There is no real evidence that stateless Huffman decoding is computationally intensive even for an 8-bit micro. Let’s see some code and some numbers.

2. Embedded application protocols can be designed to avoid ever Huffman-encoding anything of interest to the device. If a printer is using some HTTP/1.1 response headers, the upgrade to HTTP/2 is enough opportunity to change that metadata to DATA frame data. The only unavoidable case I can think of is :status, but it’s “safe enough” to assume that will be either encode 200 OK by the static table, or anything else represents failure. Correct me if I’m wrong.

3. A Huffman decoding proxy can be inserted at the USB socket relay. I’m working on a very generalized library that should hopefully handle such a task, but it doesn’t sound like such a tall order for other proxy packages even if I never finish.

Received on Thursday, 29 May 2014 02:46:54 UTC

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