Here’s my final decision: 401 is for Identification, and 403 is for Permissions.
|HTTP Code||Server Says||Server Means|
|401||Unauthorized||I’m not telling you anything until you show me some ID|
|403||Forbidden||Your ID is valid, but you don’t have clearance|
This is a little contrary to what the spec actually states, but with good reason. The full RFC includes a statement that (emphasis mine):
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.
To me, applying this rule would make 403 nearly or totally useless. If there is a file that nobody may ever access via HTTP, it’s better that the server not tell anyone about it (404). Sharing existence information would only be potentially harmful; it’s admitting that a file exists that is also important enough to protect.
As a developer, I’d rather have a distinction between “I don’t know you” and “you can’t do this” over trying to detangle both. I’m not the only one to feel this way, either.
Just because something is standardized, doesn’t mean it can’t change. Those original standards are from fifteen years ago, and the way we use the internet has changed drastically. We’re moving away from the web-addresses-as-file model and toward web-address-as-command. Holding on to irrelevant or misguided standards just because they’re standards won’t help anyone.
- More on this later. There are half-written posts, I promise. ↩