Re: Standardizing Firefox's Implementation of Link Fingerprints

On 7/10/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> If you want the resource to be named as a static representation,
> then use the hash in its real identifier -- the URI path.  That way,
> both the server and the client can verify that the representation
> fits the hash prior to its delivery and the origin server can set
> the appropriate metadata for cache-control, content-md5, etc.
There's actually 3 players in the picture: server, client, and link
provider. For example, mozilla.com can link to mirror.net for an end
user to download a file. If the hash was contained in the URI path, a
link provider could not make sure the client gets the intended file if
the file on the server is not under the link provider's control. Also
important to note, the link provider can enforce stronger security and
be trusted while safely linking to external resources.

As you pointed out earlier..
> The only component in the request chain that is even aware of
> the fragment is the UA.
This means the servers and networks don't need to be modified to
support Link Fingerprints - in fact, they don't even know if a request
uses Link Fingerprints. Modifying the servers to include a hash in the
URI path requires deploying new software on both ends - a task that
requires more resources than implementing Link Fingerprints in some
browsers or download managers.

Link Fingerprints is bar-raising exercise that requires little/no
effort from the parties involved. Servers don't change. Links have an
additional #hash(). And in the common case of no failure, the end user
sees nothing different from before, while existing clients function
normally.

Ed

Received on Wednesday, 11 July 2007 00:09:23 UTC