Þ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@gamla ~ $ nc google.org 80
GET http://www.google.is/ HTTP/1.0
HTTP/1.0 200 OK
