Re: Standardizing Firefox's Implementation of Link Fingerprints

Just a thought -- it might be more appropriate to discuss this on the  
URI mailing list <http://lists.w3.org/Archives/Public/uri/>.

Cheers,


On 2007/07/11, at 10:09 AM, Edward Lee wrote:

>
> 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
>

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Wednesday, 11 July 2007 00:24:00 UTC