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

Re: Reasons to not use huffman encoding?

From: Michael Sweet <msweet@apple.com>
Date: Fri, 31 Jan 2014 16:50:52 -0500
Cc: Gábor Molnár <gabor.molnar@sch.bme.hu>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <D4A82BEB-32A4-4813-A447-1ECBDDABB27B@apple.com>
To: Adrian Cole <adrian.f.cole@gmail.com>
FWIW, I would rather not use Huffman encoding at all, just to reduce the complexity of implementation.  IMHO it doesn't offer a compelling improvement in overall header compression...

On Jan 31, 2014, at 4:11 PM, Adrian Cole <adrian.f.cole@gmail.com> wrote:

> Thanks for the inputs.  So, seems case-by-case, with most decisions being relatively static.
> 
> if huffmanNotDisabledDueToSomeCPUConcern
> and worthItToCheckLengthWithAndWithoutHuffman 
> and foundHuffmanShorter
> huffmanEncode
> 
> Is that a fair summary?
> 
> I'm guessing that in most cases, you'll have a buffer with a known length, so above comparison is probably worth it in most cases.
> -A
> 
> 
> On Fri, Jan 31, 2014 at 10:55 AM, Gábor Molnár <gabor.molnar@sch.bme.hu> wrote:
> There are cases when encoding without Huffman simply produces smaller input (for example, if your header value consists of uncommon letters or binary data).
> 
> 
> 2014-01-31 Adrian Cole <adrian.f.cole@gmail.com>:
> 
> Hi, all.
> 
> HPACK allows the sender to decide whether or not to encode with huffman.  When, in your opinion, would the sender choose not to?
> 
> -A
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


Received on Friday, 31 January 2014 21:51:22 UTC

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