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

Re: Negotiating compression

From: David Krauss <potswa@gmail.com>
Date: Wed, 28 May 2014 09:59:15 +0800
Cc: Michael Sweet <msweet@apple.com>, Nicholas Hurley <hurley@todesschaf.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <0D9731E6-00B2-49D7-8CD1-E14E02C0899E@gmail.com>
To: "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>
The smallest embedded devices today are still 8 bit, 8051 derivatives. The smallest Iíve seen with an Ethernet interface has a M68K (ColdFire) core, 128K of program space, 32K RAM. It comes with a free HTTP client. IIRC the included demo is a webserver, but I donít know whether that fits into that particular MCU.

In the internet of things, HTTP is a sensible choice for anything, and you can be certain the device will be more susceptible to firewalls if it tries to use anything else.

Better applicability to the embedded domain is the most attractive thing about HTTP/2 to me. However, although I havenít yet implemented HPACK, the Huffman code doesnít look particularly scary. My main concern is that itís not very efficient. As for the rest, it goes away when you set the table size to zero, no?

And if the total variety of headers ever sent by the client fits into 4K, it can in theory verify that the server header table is at least so much, and then hard-code the transmitted headers against the presumed remote state, rather than actually encoding them from scratch.

Iíve not implemented HPACK, but what works for a big server handling a million connections should usually work for a tiny MCU.

On 2014Ė05Ė28, at 7:34 AM, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com> wrote:

> Realistically, the smallest embedded device are still orders of magnitude more powerful that the computers I was using at Uni or before then. If running compression was a good idea on a 286 or M68K, Iím struggling to see what classes of device youíd be concerned about where compression is a bad idea but where HTTP would still be a sensible choice?
> I also donít see a case in which enforcing support for compression of data (C-E : GZip et al.) is a good idea but compression of headers isnít, unless you have some data or observation which suggests that HPACK is significantly worse than GZip in terms of performance?

Received on Wednesday, 28 May 2014 01:59:49 UTC

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