4 ms·

> 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

> 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 https://flickr.com/settings but that would not be a user named "settings" and the same for every other alternate purpose URL

KomoD 8mo ago
> 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.
- onli 8mo ago
  Yes, I saw that multiple times in blog engines, with the entry title being the optional part.
- dylan604 8mo ago
  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.
shakna 8mo ago
> 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/consolidate-duplicate-urls https://developers.google.com/search/docs/crawling-indexing/...
- socalgal2 8mo ago
  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.
  - shakna 8mo ago
    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.
Macuyiko 8mo ago
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...

KomoD 8mo ago

> 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.

onli 8mo ago
Yes, I saw that multiple times in blog engines, with the entry title being the optional part.
dylan604 8mo ago
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.

shakna 8mo ago

> 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/consolidate-duplicate-urls https://developers.google.com/search/docs/crawling-indexing/...

socalgal2 8mo ago
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.
- shakna 8mo ago
  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.

Macuyiko 8mo ago

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...