Hacker News Reader

Comment by socalgal2 | Hacker News Reader

> I would also try to add a human-readable slug at the end, because…

No? Because what would it be based on and if you edited the thing that it's based on then the URL would either change, or get out of sync which woudl suck. You could ignore the suffix meaning flickr.com/mwichary/sets/72177720330077904-<everything-past-the-previous-dash-is-ignored> I'm not sure if that would be a positive, although I guess S.O. does something like that. The issue is other sites really want to know if it's a link to the same resource or a different resource. And while you could redirect to the new one that just makes more work for everyone.

> I would get rid of /photos

I wouldn't because then you'd had have https://flickr.com/settings but that would not be a user named "settings" and the same for every other alternate purpose URL

View on HN

> The issue is other sites really want to know if it's a link to the same resource or a different resource.

Thats what the canonical link is for, isn't it? [0]

RFC 6596 introduced it in 2012. Other websites, like search engines or social media, have been using it for a while.

[0] https://developers.google.com/search/docs/crawling-indexing/...

Yes, and? That’s a boil the ocean solution. Every app and site needs to look up urls and update where as they didn’t before.

Most apps and sites will have a thumbnail for the site. So they're already loading the page.

Other sites grab contact information or verification headers. So they also load the page.

Seems like the only people who wouldn't want to load at all, would be those places where deduplication doesn't matter in the first place.

> You could ignore the suffix meaning flickr.com/mwichary/sets/72177720330077904-<everything-past-the-previous-dash-is-ignored> I'm not sure if that would be a positive, although I guess S.O. does something like that.

That's usually how people do it.

Yes, I saw that multiple times in blog engines, with the entry title being the optional part.

I've seen these types of things break because of characters used after the dash separator would be deemed illegal by some part of the chain. However, if you delete everything after the separator just leaving the ID, the page would load. So some URL parser is choking because someone forgot to encode the URL somewhere upstream.

Just another reason to say who cares to human readable bits in the location. Most browsers hide that data anyways.

What I typically end up doing is just recalc the slug and see if it matches the provided one. If it doesn't redirect to the most up to date slug matching the id. Though who knows if those old SEO patterns still matter these days...

Reply on news.ycombinator.com