Re: Proposal: New Frame Size Text (was: Re: Design Issue: Frame Size Items) from Martin Thomson on 2013-05-11 (ietf-http-wg@w3.org from April to June 2013)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 10 May 2013 20:01:51 -0700
To: Roberto Peon <grmocg@gmail.com>
Cc: James M Snell <jasnell@gmail.com>, William Chan (陈智昌) <willchan@chromium.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Hasan Khalil <hkhalil@google.com>
Message-ID: <CABkgnnXVMnL=i2p_mDzcWLP0TNpV_wp7XhsuOTA+Tayv1aBv3Q@mail.gmail.com>

On 10 May 2013 18:30, Roberto Peon <grmocg@gmail.com> wrote:
> The memory needed for header interpretation will, for a decent
> implementation, be at worst the sum of the size of the compression context
> and the size of the receive buffer-- it will not expand once decompressed
> unless a lot of useless copying is being done.

I was going to say the same thing until I realized that most APIs will
be forced to decode Huffman-encoded strings to present.  Some
implementations might avoid this entirely, others might defer
decompression, or something along those lines, but there is probably
going to be at least some exposure to the decompressed data.

Received on Saturday, 11 May 2013 03:02:19 UTC