Proposal of new feature: handler to HttpResponseNotAllowed (status 405)

[Jorge C. Leitão]

Django allows users to define handlers to some exceptions, most notably http404, server error (status 500) and permission denied (status 403).

I here propose this feature to be extended to HttpResponseNotAllowed (status 405).

There main reason is consistency: if django has a way to create such status, it should also allow the developer to handle them.

For instance, I was planning to write handlers for some status I raise in views (mainly for debugging during live), and I'm not being able to use the decorator require_http_methods because it emits a status that I cannot handle by myself. Thus, I cannot properly judge if it was triggered by a server semantic error or by a "curious" user.

Regards,

Jorge

[Tom Evans]

On Mon, Jul 8, 2013 at 10:01 AM, Jorge C. Leitão
<jorgeca...@gmail.com> wrote:
> Django allows users to define handlers to some exceptions, most notably
> http404, server error (status 500) and permission denied (status 403).
>

In fact, django already allows you to install handlers to process any
kind of unhandled exception, by installing middleware with a
process_exception() method that handles exceptions of that type.

> I here propose this feature to be extended to HttpResponseNotAllowed (status
> 405).
>

This is a HttpResponse subclass, not an exception. handle404 does not
get involved if you return a HttpResponseNotFound response from your
view, only if you raise a http.Http404 exception. Basically:

Middleware can handle any unhandled exception before the other
exception handlers are involved.
handle403 handles uncaught django.core.exceptions.PermissionDenied exceptions.
handle404 handles uncaught django.http.Http404 exceptions.
handle500 handles all other uncaught exceptions.

Cheers

Tom

[Jorge C. Leitão]

It is unfortunate that I didn't found this on documentation.

Thanks for the clarification Tom.

Cheers,

Jorge

[Poorbahrdew .poorbahrdew]

Hi guys,

I know, this is a quite old thread, but recently I had the same issue with these decorators for the same reason: how to handle 405 responses in user friendly way?

I have found a simple solution which doesn't require to write your own middleware and I want to share it with people facing the same problem in the future :).

The solution is: another decorator, that wraps the require_POST decorator. (Google for decorator chaining, if it's alien to you.)

---------------

# the view function

@handle405 # your own decorator, see the code below

@require_POST

def myView(request):

    # ... doing fancy stuff ...

    return HttpResponse("Everything is ok, it was a POST request.")

# the trick: wrap the require_POST decorator by writing your own

def handle405(func):

def checkResponse(param):

# run the function that was modified by require_POST, param=request

ret = func(param)

if ret.status_code == 405:

return HttpResponse("Sorry, it was not a POST request.")

return ret

return checkResponse

---------------

Cheers!

Zsolt

[Tom Evans]

On Fri, Oct 3, 2014 at 10:17 PM, Poorbahrdew .poorbahrdew
<proudto...@gmail.com> wrote:
> Hi guys,
>
> I know, this is a quite old thread, but recently I had the same issue with
> these decorators for the same reason: how to handle 405 responses in user
> friendly way?
>
> I have found a simple solution which doesn't require to write your own
> middleware and I want to share it with people facing the same problem in the
> future :).

In my original response last year, I was trying to explain that this
is handled by middleware, not that you have to handle it with your own
custom middleware. I then listed out the error handlers that django
provides, noting that handler500 will handle *all uncaught
exceptions*.

Therefore, if you want to do something special with a particular
exception, like a custom exception like HttpMethodNotAllowed, you can
catch this with a custom handler500 and handle it there.

No patching of views required.

Cheers

Tom