HttpResponseUnauthorized is missing

[moep]

The attached patch adds an HttpResponseUnauthorized response (Http 401) just like HttpResponseNotFound. This status code indicates that authentication is possible but has failed or has not yet been provided.

Perhaps we should add the other codes as well?

[jdetaeye@…]

The documentation page doc/request_response.txt will need updating too...

[moep]

Updated patch to include Documentation.

[Chris Beaven]

I kind of remember a discussion about this a long while back with a negative outcome but I can't find it. I'll pass through a design decision.

When would you want this anyway - won't this open a basic http auth login window in most browsers?

[moep]

No most browser don't handle this status code and just display the html if any.

While working on this part of my project (404, 403 handling ... ) i also noticed that you can only raise an 404 but not an 403 error code ...
I would prefer if you could just raise every any code which would allow you to implement something like get_object_or_403 as well.

Perhaps one should rethink the whole issue and handle every status code the same way, without having an exception for 404.

[arien]

Replying to moep:

No most browser don't handle this status code and just display the html if any.

All browsers I know of handle this status code by prompting for credentials. ​The Django trac login page for example will return a 401 Authorization Required response:

$ curl -I http://code.djangoproject.com/login
HTTP/1.0 401 Authorization Required
Date: Tue, 22 Jan 2008 00:10:42 GMT
Server: Apache
WWW-Authenticate: Basic realm="Django project trac installation"
Connection: close
Content-Type: text/html; charset=iso-8859-1

Which browser doesn't prompt for credentials when navigating to that page?

(In this particular case any valid session cookie would log you in automatically instead of returning the 401 status, so make sure to delete those before trying.)

[Malcolm Tredinnick]

Two problems here: firstly, we aren't going to add extra classes for every possible HTTP status code. At some point we realised it just wasn't productive, since the only real difference is the status. Consequently, you can pass the status code into the HttpResponse initializer. Secondly, 404 and 500 are treated specially as exceptions. But, again, it's not worth adding all error codes as exceptions. They are just normal responses. More descriptive errors (such as PermissionDenied) should be raised if people are meant to handle them. That's more generally useful than an exception tied to an HTTP status code (since the exception might not ultimately be handled by returning that status code).

[anonymous]

lol.

I'd be super embarrassed if i was the asshole who decided to set this to 'wontfix'.

I can't believe this still doesn't exist.

[Aymeric Augustin]

The man who set this to wontfix is without doubt the most respected person in the Django community.

Read ​https://www.djangoproject.com/weblog/2013/mar/19/goodbye-malcolm/ if you'd like to know why.

I would be very embarrassed if I got caught pissing on someone's grave like you just did.