3 ms·

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re d

> Strong disagree. You do not want both URLs to return the same content; you can have alternatives redirect to the canonical URL; but think through why you’re doing it: who is benefited by the redirect? At least with regard the with/without slash redirects there is value in these: sometimes the user copy-pastes the URL but forgets the final slash, sometimes the application he is using for bookmarking, sharing, etc. drops the slash; sometimes even the site owner forgets be consistent. Thus having those redirects in place means not having dead links pointing to your site. With regard the `.html`, with and without, it's a matter of taste... However, the same point applies, perhaps you've been inconsistent along the years, thus having redirects saves the dead links... However you are right about the "canonical" URL: for search engine purposes, having a single page serving the content, and the rest being redirects, is kind of essential. (Or at least having a `<link rel="canonical" ...>` if not a redirect.) > Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong. It is when you don't want dead links. :)

chrismorgan 4y ago
You seem to have missed a good chunk of what I said. But to address some particular points: > sometimes the application he is using for bookmarking, sharing, etc. drops the slash Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to happen would break many other things too, so that it doesn’t seem likely. > perhaps you've been inconsistent along the years, thus having redirects saves the dead links... And so I strongly advocate for retaining such redirects. Just not gratuitous support for other things. > It is when you don't want dead links. I said for the sake of it. If by “dead links” you mean “existing URLs that worked in the past”, that’s not “for the sake of it”, but good cause. But if you’re speaking about proactively allowing things that never worked in the past, that’s exactly what I’m arguing against. I want robust justification for every extra URL that is supported, of the machine or human that is likely to encounter it and why. (As an example of this, I’d honestly quite enjoy returning 400 for requests with unknown query strings parameters, which in the context of static websites mostly means any query string, in order to truly have only one URL for the content; but I acknowledge that this is not pragmatic because it’s not uncommon to inject additional query string parameters, typically for the purpose of spying on users in unwanted utm_* parameters and the likes.)
- deleted 4y ago
  [deleted]

chrismorgan 4y ago

You seem to have missed a good chunk of what I said. But to address some particular points: > sometimes the application he is using for bookmarking, sharing, etc. drops the slash Do you happen to have any evidence of this? I’ve heard it mentioned very occasionally, but never seen it, including any probability of it in logs (though I have seen more bizarre things), and the only ways I can imagine it being likely to happen would break many other things too, so that it doesn’t seem likely. > perhaps you've been inconsistent along the years, thus having redirects saves the dead links... And so I strongly advocate for retaining such redirects. Just not gratuitous support for other things. > It is when you don't want dead links. I said for the sake of it. If by “dead links” you mean “existing URLs that worked in the past”, that’s not “for the sake of it”, but good cause. But if you’re speaking about proactively allowing things that never worked in the past, that’s exactly what I’m arguing against. I want robust justification for every extra URL that is supported, of the machine or human that is likely to encounter it and why. (As an example of this, I’d honestly quite enjoy returning 400 for requests with unknown query strings parameters, which in the context of static websites mostly means any query string, in order to truly have only one URL for the content; but I acknowledge that this is not pragmatic because it’s not uncommon to inject additional query string parameters, typically for the purpose of spying on users in unwanted utm_* parameters and the likes.)

deleted 4y ago
[deleted]