Re: A proposal for Shared Dictionary Compression over HTTP


You raise an interesting point.  SDCH was designed to be applied to
the message body before gzip (since cross-payload redundancy is much
harder to detect after gzipping the payloads).  One of the differences
between the two sets of headers is that transfer encodings must be
applied after and removed before content encodings, since transfer
encodings are properties of the message and content encodings are a
property of the entity inside the message.  So, we have a choice:
either we indicate both SDCH and gzip in the Content-Encodings, or
both in the Transfer-Encoding header.  Since the prior art for gzip is
to indicate it in the Content-Encoding header (a holdover from the
HTTP/1.0 standard as I understand), we proposed putting sdch there as

>From my reading of the standard, it would be more in keeping with the
HTTP/1.1 standard to put both encodings (gzip and sdch) in the
TE/Transfer-Encoding headers, but it is not clear that it would be
more practical.

We'd be happy to hear others' opinions on this.


On Wed, Sep 10, 2008 at 4:17 AM, Yves Lafon <> wrote:
> On Mon, 8 Sep 2008, Wei-Hsin Lee wrote:
>> Hi,
>> Over the last few weeks we've been experimenting with a way to get better
>> compression for HTTP streams using a dictionary-based compression scheme,
>> where a user agent obtains a site-specific dictionary that then allows
>> pages
>> on the site that have many common elements to be transmitted much more
>> quickly.
> One question, why using Accept-Encoding/Content-Encoding instead of
> TE/Transfer-Encoding ?
> Cheers,
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>        ~~Yves

Received on Wednesday, 10 September 2008 16:32:41 UTC