W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

RE: A proposal for Shared Dictionary Compression over HTTP

From: Brian Smith <brian@briansmith.org>
Date: Mon, 8 Sep 2008 19:55:58 -0500
To: "'Ian Hickson'" <ian@hixie.ch>, <ietf-http-wg@w3.org>, "'Wei-Hsin Lee'" <weihsinl@google.com>
Message-ID: <218960D60C56465089DB207075590077@T60>

Ian Hickson wrote:
> On Mon, 8 Sep 2008, Wei-Hsin Lee wrote:
> > 
> > We have a paper that we wrote to describe this idea, which 
> > I have put online here: http://groups.google.com/group/SDCH
> For those of you not used to Google Groups, the paper is here:

It seems to me that AJAX can be used to solve this problem in a simpler
manner. Take Gmail for example--it downloads the whole UI once and then uses
AJAX to get the state-specific data. The example from the PPT showed a 40%
reduction in the number of bytes transmitted when using SDCH (beyond what
GZIP provided) for google SERPs. I bet you could do about that well just by
AJAXifying the SERPs (making them more like GMail) + using regular HTTP
cache controls + using a compact, application-specific data format for the
dynamic parts of the page + GZIP. Maybe Google's AJAX Search API already
does that? In fact, you might not even need AJAX for this; maybe IFRAMEs are

I also noticed that this proposal makes the request and response HTTP
headers larger in an effort to make entity bodies smaller. It seems over
time there is an trend of increasingly large HTTP headers as applications
stuff more and more metadata into them, where it is not all that unusual for
a GET request to require more than one packet now, especially when longish
URI-encoded IRIs are used in the message header. Firefox cut down on the
request headers it sends [2] specifically to increase the chances that GET
requests are small enough to fit in one packet. Since HTTP headers are
naturally *highly* repetitive (especially for resources from the same
server), a mechanism that could compress them would be ideal. Perhaps this
could be recast as transport-level compression so that it could be deployed
as a TLS/IPV6/IPSEC compression scheme.


[1] http://www.whatwg.org/specs/web-apps/current-work/#offline
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=309438
Received on Tuesday, 9 September 2008 00:56:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC