3 ms·
As an aside, it would be interesting to adopt a convention where certain links included a hash of what it pointed to, avoiding the case that the (sub-)resource
by javajosh 10y ago
As an aside, it would be interesting to adopt a convention where certain links included a hash of what it pointed to, avoiding the case that the (sub-)resource changed out from underneath the link. This implies that you'd want to link to a specific version of a (sub)resource. E.g. you could do something like what github does with:
https://github.com/USER/PROJECT/commit/COMMIT_HASH#DIFF_HASH https://github.com/USER/PROJECT/commit/COMMIT_HASH#DIFF_HASH
where the DIFF_HASH is a fragment pointing to a particular resource within the commit.
- zackbloom 10y agoThere is a spec called Subresource Integrity which does something similar for resources included inside HTML files. Doing it for links is problematic though. What do you do if the hash doesn't match though? Show an error? Show the destination page anyway? What happens if the author _wants_ to change the content? Should links be immutable?
- javajosh 10y agoCool, that's almost exactly the idea[1]. Although I would argue that resources should be immutable and versioned. Actually jsbin has a good representation there where you have: http://domain/resource/version and `http://domain/resource` http://domain/resource` just points to either the latest version or to a specific one that the author chooses. The big difference between SRI and my proposal is that the hash go on the URL rather than an attribute. [1] https://www.w3.org/TR/SRI/ https://www.w3.org/TR/SRI/