Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

Parent Full thread

> check that with/without .html extension serving works properly; (i.e. /some-file.html should perhaps return the same content as /some-file, or even better, choose one as canonical and redirect for the other one;)

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?

If your canonical URL is /example, I see no reason at all to support .html. If it’s /example.html, I see no particular reason to support /example or /example/. If it’s /example/, there may be a smidgeon of value in supporting /example. If it’s /example and you ever have paths below that (/example/example), then there may be slight value in supporting /example/.

If you switch from one format to another, do ensure that all existing URLs work. I used to use .html, so my old *.html URLs now redirect to */, but only for old articles, not new ones that were never .html, because I like being fancy like that.

But overall, I say: for at least the .html and trailing slash suffixes, no software should ever be causing these errors (I have heard rumours of improper transformations once or twice, but seen no evidence, and neither of these are ambiguous “will the automatic linkifier include or exclude that punctuation at the end” cases), so it’s all about humans and what incorrect URLs they might type out. And most of these sorts of things, people just won’t do.

Supporting more things for the sake of it is not a virtue. There is value in failing early on incorrect input. Postel was wrong.

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

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

Reply on news.ycombinator.com