How does Django's View.dispatch() choose a handler method, and when does a class-based view answer 405 Method Not Allowed?

## The dispatch algorithm Every Django class-based view inherits `dispatch()` from `django.views.View`. Its job is to map the HTTP method to a Python method on the view instance. The whole algorithm fits in three steps: 1. Compute `method = request.method.lower()`, so `GET` becomes `get`. 2. If `method` is in the class attribute **`http_method_names`**, look up `getattr(self, method, self.http_method_not_allowed)`. 3. If it is not in the list, use `self.http_method_not_allowed` directly. Then call the chosen handler with `(request, *args, **kwargs)`. `http_method_names` is therefore an **allow-list**, and a matching method on the class is the second condition. Both must hold for a handler to run. The default list is: ```python ["get", "post", "put", "patch", "delete", "head", "options", "trace"] ``` ## When the answer is 405 `http_method_not_allowed()` is the fallback in both branches. It returns an `HttpResponseNotAllowed` (status **405**) with an empty body and logs a warning through `django.request` (Django logs 4xx responses as warnings). The cases that reach it: | Request | View defines | Outcome | |---|---|---| | `GET` | `get()` | `get()` runs | | `HEAD` | `get()` only | `get()` runs, because `setup()` set `self.head = self.get` | | `POST` | `get()` only | 405: `post` is listed but not defined | | `TRACE` | nothing special | 405: listed by default, but `View` has no `trace()` | | `PROPFIND` | anything | 405: not in `http_method_names` at all | | `OPTIONS` | nothing special | 200 from the built-in `View.options()` | A 405 is not a 404: the URL pattern matched and the view ran; only the verb was refused. (How a router in general decides between 404 and 405 is a framework-neutral topic; in Django the URL resolver ignores the method entirely and leaves the decision to the view.) One caveat when testing by hand: middleware runs before the view, so an unsafe request without a CSRF token can be rejected with 403 before `dispatch()` is ever reached. The table describes what the view itself returns. ## The Allow header Both the 405 response and the `OPTIONS` response list methods through the private helper `_allowed_methods()`, which returns the **uppercased** names that are in `http_method_names` **and** exist on the instance. Because it checks the instance after `setup()`, a view with only `get()` advertises `GET, HEAD, OPTIONS`: `head` exists thanks to the alias and `options` is inherited from `View`. `View.options()` returns an empty `HttpResponse` (status 200) with `Allow` set and `Content-Length: 0`. It is a real handler, so it obeys the same allow-list rule as everything else. ## Narrowing or widening the verbs - **Narrowing** — set `http_method_names = ["get", "head", "options"]` on a read-only view and `POST`, `PUT` and friends return 405 even if a mixin happens to define `post()`. Beware of `http_method_names = ["get"]`: it also removes `head` and `options`, so `HEAD` and `OPTIONS` both become 405 even though handlers for them exist. - **Widening** — to accept a verb that is not in the default list, add its lowercase name to `http_method_names` **and** define a method with that name. Either half alone still produces 405. - **Removing a handler per route** — you cannot pass `get=None` to `as_view()`; it rejects HTTP method names as keywords. Subclass or override `http_method_names` instead. ## Customising the refusal `http_method_not_allowed()` is a normal method, so a view can override it — for example, to render a friendlier page for browsers or to add a structured body for an API client — as long as it still returns a 405 with an accurate `Allow` header. Returning 404 instead hides the resource's existence but breaks clients that rely on `Allow`. ## Testing the verb handling A view's method policy is easy to pin down in tests with Django's test `Client`, which does not enforce CSRF checks by default: - `self.client.post(url)` on a GET-only view should give `response.status_code == 405`. - `response.headers["Allow"]` should list exactly the verbs you intend to expose. - `self.client.options(url)` should return 200 with the same `Allow` value, or 405 if `options` was deliberately left out of `http_method_names`. Pinning `Allow` in a test catches the case where a mixin quietly adds a `post()` handler to a view that was meant to be read-only. ## Common misunderstandings - Believing Django's URL resolver matches on the HTTP method: it does not; the same pattern always reaches the view. - Expecting a missing handler to raise `AttributeError` and a 500: the `getattr` default turns it into a 405. - Writing a `head()` method to make `HEAD` work: unnecessary unless it must differ from `get()`. - Assuming `trace` is served because it appears in the default list.