Hacker News Reader

Comment by seagreen | Hacker News Reader

This is a make-work trap for conscientious people.

If it's more efficient for your business/project to change your URIs when going through a website design, go ahead (with the knowledge that you'll lose some traffic, etc.)

Seriously, there's no reason to feel guilty over this. It's not your fault, it's the fault of a system that built two UIs into every website (the website's HTML and the URL bar -- the second of which is supposed to be useful for browsing and navigation just like the first).

If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links instead of trying to fix it at the social level (which will never work anyway, the diligent people that care about these things will always be just a drop in the bucket).

View on HN

I work for a publisher that produces several articles a day that include external links for reference. More and more I seem to be coming across cases where those links are now broken. In the near future, I will startup an automated script that checks for broken links (and I'm guessing I may have to get it warning on redirects since certain bad actors use redirects when they should be using 410).

When I have some decent results, I'll be ensuring the editorial team is aware of which sites in particular are prone to breaking links, and which they can trust. The net effect will be that we will be less likely to drive traffic to certain domains. Whether enough other people will do this to make any kind of meaningful difference is unknown, but it's certainly better to be a trustworthy site that it can't hurt to link to.

On a related note, I learnt this week that taken-down YouTube videos are a PITA. Not only do they give a 200 when requested, they also give zero results when looked-up via the youtube api. Sure, they can still be treated as a 'broken link' from our end, but it would be nice to be able to differentiate between a video that was taken down and one that may never have existed in the first place.

There's always the Internet Archive Wayback Machine "save page now" feature. Wikipedia's been pretty enthusiastic about using it to make sure that external links remain available -- and that the cited version is available.

What I want to do is make an extension that sends a request to web.archive.org/save/{URL} whenever you visit a webpage. To prevent flooding, I would make it only send a request for a specific URL once a month.

> If W3C actually cared about links continuing to work, they would fix it at the technical level by promoting content-addressable links [...]

Now, while I very much like the idea of content-addressable systems, that is not the solution to this problem. Addresses/names often are used to identify more abstract things than "this sequence of bytes". For example, company A's current list of prices is not a fixed sequence of bytes, but rather an abstract concept that refers to information that varies over time. The purpose of a name in this case is that it allows you to obtain an up-to-date version of some information.

A name that is derived from the content that you want to obtain cannot possibly do that job. Only names maintained by people who understand the continuity of those varying byte sequences can do that.

Heh, you got me:) I agree the situation is more complicated than I described.

My main response to this is: just because we can't always use content-addressable links doesn't mean we shouldn't use them where we can. I'm sure you see where I'm going with this. When pirate movie websites have a 1000x more rock-solid way of identifying content than the NY Times we have a problem.

But even in the most inhospitable situations like the one you describe we can still do better. Content-addressability won't help, agreed. How about promoting UUID style non-human readable paths instead? One of the reasons links change is that the content changes slightly and the name goes out of date. Perhaps in your case legal says "these prices may be up to ten minutes out of date, we can no longer call that path /prices/current/feed". If the path was /3824-3822-4864 this wouldn't be a problem. Information about what that endpoint returns can be placed in a description field or in the docs where it can be kept up-to-date without breaking links.

I don't think that would make any real difference. Links break because people switch to new software that has different URIs for the content and they don't see the problem, or due to software that has stupid mechanisms for generating URIs, that's it. URIs changing due to a concious decision to change the URI are the rare exception, it's mostly just a side effect that noone cares about.

Also, in your specific example, it would still be possible to replace the old content with a document explaining the change and linking to the new URI, or possibly even an HTTP redirect. Plus, a semantically meaningless name might still not prevent the problem, as there just as well could be legal consequences if you have communicated before that this URI provides "current prices" via some other means than the URI itself.

Well exactly. You can change your URLs if you want, but it's not cool. You can choose not to be cool.

Working on IPFS/Tahoe-LAFS/Camlistore/BitTorrent is cool. Doing make-work isn't.

Like a lot of things a decade and a half ago, the W3C was pushing a good idea to the point of it being an unrealistic ideal, in an environment where most people were doing the exact wrong/opposite thing.

Now the situation is different, and a lot of these messages have finally sunk into the mainstream. I think you're right; there's no need for an army of purists to keep driving these points home. We get it, we know where the trade-offs are. This needs to be interpreted in a larger context of what was going on at the time.

Oh, well said!

Any strong language I used was directed at me as of a year ago who was wasting time on redirects no one would ever use, not the original authors.

Reply on news.ycombinator.com