- From: Joseph Pecoraro <joepeck02@gmail.com>
- Date: Tue, 14 Jul 2009 12:21:17 -0400
> On Jul 13, 2009, at 3: 01PM, Aryeh Gregor wrote:
> How about you have an extra HTTP header like "X-Content-Hash"? This
> could provide a SHA256 hash (or something else that looks safe for
> now, progressively upgradeable) of the content. The browser can keep
> its cached copies of these files indexed by hash. If it tries
> downloading a file, and notices that the hash is the same as a file
> already downloaded, it can terminate the HTTP connection and use the
> existing file (even if it's from a different site). It will then
> proceed as though it had actually downloaded the file: e.g., it will
> respect the Expires headers separately (two sites might serve the same
> file but have different expectations about how likely it is to
> change).
I think thats brilliant. Its a cache that works across all sites.
> On Jul 13, 2009, at 3: 01PM, Aryeh Gregor wrote:
> The most obvious place to solve this seems to be HTTP, not HTML. HTTP
> is closer to the resource itself. If you do something with HTML, like
> an extra <link> attribute, then you're going to get authors updating
> the HTML but not the thing it points to or vice versa. An ETag-like
> solution would be implemented either in the web server or whatever
> script is serving the content, and those should always know whether
> the file has changed. (Modulo pathological behavior like something
> changing the file and then forging the mtime/ctime.)
I agree.
> On Jul 13, 2009, at 4: 20PM, Aryeh Gregor wrote:
> Does anyone have statistics on how useful this would be in real life?
> I suspect only marginally.
I think this is the most important aspect of this idea. We don't yet
know if this is worth doing yet.
It is likely only preventing the initial download of some files.
However some of the initial framework sizes are getting hefty: (These
were the sizes just pulled from google's hosted libraries for the
latest versions)
91K dojo.xd.js
79K ext-core.js
182K jquery-ui.min.js
56K jquery.min.js
127K prototype.js
2.6K scriptaculous.js
10K swfobject.js
27K yuiloader-min.js
I'm guessing that mobile browsers would benefit from not needing to
download a few of those 100KB downloads and use up an HTTP Connection
to do so. And speaking of mobile, there are some mobile specific web
application frameworks (I'm thinking of ones for iPhone web apps) that
don't have a single cache point (like google) that weigh in pretty
heavily.
Real statistics would make it obvious wether or not this is a good
idea. But even still, I like the HTTP idea, because at that point its
just a more efficient way to cache files, by content, across all the
entire web, rather then site specific and by name/URL.
- Joe
Received on Tuesday, 14 July 2009 09:21:17 UTC