Re: Negotiating compression

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.