So, one of the complaints I've heard from a few people now is the fact
that 404 is the only thing one can raise as a HTTP error - there are
plenty of others, such as 403 and 405, that could be useful to raise
back to the client.
This didn't used to be much of a problem with function-based views - you
could just return a custom HTTPResponse - but now we have class-based
views that's not always possible from every function (as some functions
return intermediary values, and returning a HTTPResponse there isn't
going to help).
In the interim, I can use something which catches custom exceptions in
my dispatch()/GET()/etc functions, but I'd like to propose that we
extend core Django to allow for all the major HTTP error status codes to
be raised as exceptions. I have a rough plan of how this would work:
- Modify the base handler to catch a general exception base class
rather than the special-case of Http404 and exceptions.PermissionDenied
- Write this new base HttpException class that knows how to serve its
own errors. By default, make it serve the template <error_code>.html (to
replicate the old handler404 and handler500 behaviour). People can
override these classes to change their template/view behaviour, and
configure Django to use them as specified below.
- Modify Http404 to use this new base class, and also implement the
technical 404 response if debug mode is on. Also rename to HttpNotFound,
but keep the old name for backwards-compatability.
- Modify the exception-catching code to raise a HttpInternalServerError
with the right attributes. HttpInternalServerError will then implement
the technical 500 response.
- Provide a whole range of other base exceptions (e.g. HttpForbidden).
- Start handler404 and handler500 on a deprecation path, and replace
them with a configuration dictionary HTTP_EXCEPTION_CLASSES =
{status_code: "path.to.class"}.
Obviously this is a bit late for 1.3, but if people are amenable to it
I've got a few changes I can start on a branch already. We keep running
into this at /dev/fort and in my own personal projects, and I figured it
was better to ask people while the idea was fresh in my mind.
(Also note the above implementation plan is very rough. Criticism of it
is very welcome.)
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
