W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] hash sum tags of binary files and code blocks?

From: David Wilson <dw@botanicus.net>
Date: Mon, 13 Jul 2009 17:39:58 +0100
Message-ID: <98edab2e0907130939p48c03ddcg74f981bbc58cb5fb@mail.gmail.com>
2009/7/13 Christian Nygaard <christiannygaard at gmail.com>:
> What if one included hash sums of every binary file in html tags, plus
> embedded hash sums in streaming file blocks, then the client would never
> need to look at time stamps/expire headers to determine if it could cache
> the objects. That would make caching very easy on mobile devices with slow
> datalinks, make it possible for service providers to cache objects globally
> for their customer base. One could also augment whole code blocks with hash
> sums for example css this could possibly be more efficient than time expire.
> <img src="example.jpg" md5="f2bd08fae5adb96c9befa02bddb4a90c">

How would this interact with HTTP Accept header? It seems each
resource would be required to have only a single presentation, and
that the HTML was intimately aware of the details of that
presentation, or alternatively intimately aware of what presentation
the user agent would request.

> <hash md5=bda497e29a81a038208ab94101e2e793" skipaheadlines=10>
> <style>
> ....
> </style>
> </hash>
> <link rel="stylesheet" type="text/css" href="external-style-sheet-file.css"
> md5="dee0b8572297fe4e3b004cfe188ecad3"/>
> no need to load that style sheet ever again if it's contents has not
> changed.

This scheme doesn't really fit HTTP at all. However that's not to say
it's interesting. In fact swathes of research have been devoted to
designing access layers like this (they're often called content
addressable networks). Introducing little bits of it into HTML seems
like the wrong layer to be working on.


Reality is that which, when you stop believing in it, doesn't go away.
  ? Philip K. Dick
Received on Monday, 13 July 2009 09:39:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC