News for hackers. Stuff that matters.

A comment on The History of the URL: Path, Fragment, Query, and Auth. Parent comment

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 ]