Hacker News Reader

Comment by holman | Hacker News Reader

We do that to avoid leaking the presence of the repository, if it's private. It's a bit of a pain, but privacy's important to us.

View on HN

Thank you for this, some of us take notice of 404-for-security responses like these and appreciate it.

Perhaps, when the link could be a private repository, the error page should state it's either missing or inaccessible.

All we need is an error code 402.5 "plausible deniability between unauthorized and not found"...

The spec actually uses a 404 specifically for this purpose: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Sure, and everybody who has read the spec knows that. Alas, that's 1% of your user base.

For the rest of your users it wouldn't hurt to say, "You might see something different if you're logged in." Or if they are logged in, saying, "Were you expecting something different? Maybe you just don't have access yet."

Wait, we cant hold github to account for making linkrot and not applying the spec, but when the spec is implemented by them, for good reason, say "but 1% of your user base reads the spec". Thats a bit of a double standard.

Are you talking to me? I don't think I said anything like the first half of that.

Reasonable compromise, although they'd have to use that version of the 404 page for any URL that could possibly a repository.

I think that is one of the biggest mistakes github did. I don't care what the spec says, you should always default to 401, so that requests can be retried with auth. Then after getting through the 401, you should fire the 404 or 200 (as the case may be).

Reply on news.ycombinator.com