[whatwg] Caching of identical files from different URLs using checksums

[Bjartur Thorlacius]

Þann lau 18.feb 2012 13:45, skrifaði Sven Neuhaus:
> The relevant section from RFC 3986 reads:
>
>    "The fragment identifier component of a URI allows indirect
>     identification of a secondary resource by reference to a primary
>     resource and additional identifying information.  The identified
>     secondary resource may be some portion or subset of the primary
>     resource, some view on representations of the primary resource, or
>     some other resource defined or described by those representations."
>
> This description is not contradicting the use of checksum as fragment
> identifiers. They are "additional identifying information."
I beg to differ. I interpret the RFC as stating that the fragment 
identifier allows indirect identification of a secondary resource. The 
fragment identifier itself is whatever information is needed to derive 
the secondary resource from the primary resource. That is, you need 
*both* a "reference to a primary resource" (i.e. an URI with no fragment 
identifier) and "additional identifying information" (i.e. the fragment 
identifier).

 >     The fragment identifier component of a URI allows indirect
 >     identification of a secondary resource by {reference to a primary
 >     resource and additional identifying information}.

A checksum of (a representation body of) the primary resource identifies 
(said representation body of) the primary resource, not any secondary 
resource derived therefrom.

And as has been pointed out previously, representations of resources are 
frequently obsoleted. Existing caching mechanism take care of that 
already, without requiring every reference to be updated on every 
obsolete. The problem you have mentioned is duplicate identifiers (that 
undermine the very raison d'être of identifiers).

Another solution would be to add a host attribute to linking elements 
(script, link, etc) that specifies a domain name of an endorsed CDN that 
will serve the resource (and ideally a public key). HTTP/1.1 mandates 
support for but forbids requests of the form <METHOD URI "HTTP/1.0">. 
IIRC the current RFC forbids, but mandates support for, such requests. 
The seventeenth httpbis draft OTOH explicitly allows absolute URI in 
request lines, at least to proxies.

bjartur at gamla ~ $ nc google.org 80
GET http://www.google.is/ HTTP/1.0

HTTP/1.0 200 OK