The History of the URL: Path, Fragment, Query, and Auth

Re:The History of the URL: Path, Fragment, Query, and Auth by javajosh on Monday July 18, 2016 @09:12PM (#12118928)

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

where the DIFF_HASH is a fragment pointing to a particular resource within the commit.

[ Parent | on HN ]

Re:The History of the URL: Path, Fragment, Query, and Auth by zackbloom on Tuesday July 19, 2016 @09:29AM (#12121592)

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

[ Parent | on HN ]

Re:The History of the URL: Path, Fragment, Query, and Auth by javajosh on Tuesday July 19, 2016 @12:08PM (#12122538)

Cool, 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` 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/

[ Parent | on HN ]