It's common for network services to squash 404 (not found) and 403 (permission denied) responses into the same response, so as to avoid giving away whether a thing exists at all that you're not allowed to see.
You can see why they do it, but it is annoying, especially if you're not alert to the possibility. You might start trying to debug the wrong problem: checking and double-checking the URL spelling when you should have checked your credentials. Or vice versa, depending on whether the site is pretending everything is 404, or pretending everything is 403.
(Worse, the confusion spreads to sites which _do_ separate the two errors. Once you've started mentally conflating the two, you waste time checking the wrong things even when the error message truthfully told you which thing to check.)
But which is _more_ annoying, of the two?
… actually, today's case of this turned out to be neither.
I was inspired to post the poll by what I thought was a 403 annoyingly misrepresented as 404. But it turns out it was some kind of 5xx transient failure misrepresented as 404. OK, _that_ is worse!
@simontatham had a live production webservice reporting 4xx errors via a redirected page *saying* 404 or whatever, but with a 200-OK response code.
loadbalancer healthchecks hate this one simple trick
