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
