7 ms·
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.
by holman 13y ago
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.
- Strilanc 13y agoPerhaps, 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"...
- holman 13y agoThe spec actually uses a 404 specifically for this purpose: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
- wpietri 13y agoSure, 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."
- bowyakka 13y agoWait, 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.
- wpietri 13y agoAre you talking to me? I don't think I said anything like the first half of that.
- petertodd 13y agoReasonable compromise, although they'd have to use that version of the 404 page for any URL that could possibly a repository.
- skyebook 13y agoThank you for this, some of us take notice of 404-for-security responses like these and appreciate it.
- 3pt14159 13y agoI 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).