W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2012

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 19 Feb 2012 09:55:08 +0100
Message-ID: <4F40B8EC.1020703@gmx.de>
On 2012-02-18 14:45, Sven Neuhaus wrote:
>>> ...
>>
>> Stop here. That's not what the fragment identifier is for.
>>
>> Instead, you could specify the hash as a separate attribute on the
>> containing element.
>
> 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."

..but it goes on saying:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications."

> This description is not contradicting the use of checksum as fragment
> identifiers. They are "additional identifying information."

It is contradicting the concept of being defined by the media type.

> However, if there is a consensus that checksums shouldn't be stored in
> the fragment part of the URL, a new attribute would be a good alternative.
>
> Regards,
> -Sven Neuhaus
>

Best regards, Julian
Received on Sunday, 19 February 2012 00:55:08 UTC

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