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

Re: Negotiating compression

From: Michael Sweet <msweet@apple.com>
Date: Wed, 28 May 2014 15:28:06 -0400
Cc: Johnny Graettinger <jgraettinger@chromium.org>, Eliot Lear <lear@cisco.com>, Nicholas Hurley <hurley@todesschaf.org>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <4ACB1358-5A3F-4A96-8B17-839121160C4B@apple.com>
To: "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>

On May 28, 2014, at 3:09 PM, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com> wrote:
> From: Michael Sweet [mailto:msweet@apple.com] 
>> And these printers offload encryption and print data processing to dedicated silicon (wouldn't be feasible otherwise).
> Now that's an interesting argument against HPACK - the lack of dedicated silicon to support it. Not having played in the embedded space for a few years, how easy is that to get around?

You can still do a software solution, but depending on how constrained you are that solution might cause unwanted performance degradation or prevent you from doing some key function (like answer an incoming fax).  I'm hoping this kind of constraint will work itself out in another 5 years (price of faster SoCs keeps coming down, more network connected services for MFPs, etc.) but in the meantime I'm bringing this up as an issue for today's HTTP-using hardware.

(FWIW, if I am reading Richard's CWS stats correctly on request header sizes, it looks like the vast majority of all web requests use less than 1k of headers, which with the static header table would be further reduced - sure seems like we can get the initial GET to the server out in one packet even without Huffman...)

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 28 May 2014 19:28:38 UTC

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