Also, technically, you can return 401 for either "unauthenticated" (you need to pass authentication information) or "unauthorized" (you passed authentication information but it wasn't acceptable), depending on the nature of what you need.
HTTP Authentication requires a lot of care to interact with the browser's authentication flow and UI.
I worked on a site for several years that used HTTP Digest authentication. We finally gave up on it and switched to the standard form-and-cookie approach, because the browser authentication flows had so many bugs, quirks, per-browser idiosyncrasies, and other issues to work around.
I've never implemented the status codes for browser purposes - only for APIs.
HTTP Digest looks interesting, but I think I'd generally feel more comfortable just using HTTP Basic over HTTPS. Or better, of course, just doing it yourself with some signed cookies.
Why not? 401 seems like a fine fit if your client doesn't need to differentiate between authentication and authorization; most don't need to at all.
Also, you can fail authorization without passing authentication. For instance, you could be authorized by ip range or something unrelated to any of the data in the http request.
Wut. Most clients don't need to differentiate between "you're not allowed to do that" and "you're not logged in"? Those things require totally different reactions, no?
> "unauthorized" (you passed authentication information but it wasn't acceptable)
That's still "unauthenticated". "Unauthorized" means that you were authenticated (i.e. the server knows who you are), but you are not allowed (i.e. authorized) to execute the requested operation. So the correct names would be "401 Unauthenticated" and "403 Unauthorized".
Cf. "Windows 10", which had to a version number because people were looking for a "Windows 9" (i.e. Windows 98 & Windows 95) prefix in a version name string despite it being available as direct numeral values.
Feel free to be horrified, but you'd be a bit naive to be surprised.
> (I'd likely be horrified to learn that something out there critically depends on the Reason Phrase…)
IIRC, the 8xxx RFCs have specified that you must read the reason and that the code itself does not fully specify the result because there have been some custom codes that overlap on number.
the 8xxx RFCs? Did you mean the newer 7xxx ones? If so, they say,
> The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the reason-phrase content.
I'm not aware of any highlevel HTTP RFCs in the 8xxx range.
(I'd likely be horrified to learn that something out there critically depends on the Reason Phrase…)