Le 13 nov. 2006 à 1:39, ryan king a écrit :
On Nov 8, 2006, at 8:28 AM, Ian Hickson wrote:
Given the various mechanisms that already exist to do this, it
seems like
adding yet another one would be a bad idea.
I concur. If people are already using these technologies, we could
learn from their usage and find ways to improve the technology. If
they aren't being used widely, it would be wise to question whether
there is demand for this functionality.
I'm sure there is demand. A lot of software download pages already
give you MD5 or SHA-1 digests values to check the validity of the
downloaded file, but it's trouble to check them manually and people
rarely do so.
I see only two mechanisms that do what the hash attribute would do:
it's the hash microformat[1] and link fingerprints[2]. All others
require either special URIs schemes[2] which won't work in today's
browsers, or are attached directly to the file, like the md5-digest
HTTP header, which means that a tampered file is very likely to get
its digest updated accordingly.
[1]: http://microformats.org/wiki/hash-examples
[2]: http://mdhashtool.mozdev.org/lfinfo.html
[3]: http://magnet-uri.sourceforge.net/
I'm beginning to think that the link "fingerprint" method is best
solution because the hash is more portable as part of the URL. I
could for instance copy a fingerprinted URL right into this email:
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
and a knowledgeable browser receiving this URL would know how to
check the validity of the received document. The two concerns I have
with it is that it somewhat distorts the concept of a fragment
identifier, and it's generally going to be lost if there is any
redirection (although a browser that knows about fingerprints could
keep them across redirections).
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
