In a web framework, what is returned by default when a request's path matches a route but its method does not?

A request can miss the route table in two different ways, and which of them the framework can *see* decides what the client is told. This is one of the few places where an internal data-structure choice is visible from outside the process. ## Two ways a router can miss - **The path is unknown.** Nothing in the table describes that path under any method. There is no more information to give; the unmatched-route fallback answers. - **The path is known, the method is not.** The table has entries for that path, but none for the method that arrived. The framework holds a genuinely more useful fact: *this resource exists, you used the wrong verb*. A router whose lookup is path-first and method-second can distinguish those cases for free, because it lands on the path node and then fails to find the method. A router that hashes path and method together into one key cannot: both cases come back as "absent", and the second is reported as if it were the first. ## What each default tells the client | Default | What the client learns | Why a framework picks it | |---|---|---| | `405 Method Not Allowed` | The path exists; try another method | The router can see the distinction and passing it on is the most useful answer | | `404 Not Found` | Nothing useful about the path | The lookup key fuses path and method, or existence is deliberately not disclosed | | Handler runs and rejects | Whatever the handler says | Method checking was left to application code rather than the route table | The third row is worth naming as an anti-pattern rather than a design: when method filtering lives inside a handler instead of in the route declaration, the framework's built-in behaviour never fires, and the response shape is whatever that handler happens to write. ## Why some frameworks prefer 404 on purpose Answering `405` confirms the path is real. On a surface where the route table itself is sensitive - administrative endpoints, internal tooling, anything whose existence you would rather not advertise - a uniform `404` for both an unknown path and a wrong method removes that oracle. The cost is paid by legitimate clients, who lose a precise hint and see a misleading "does not exist" while debugging. Treat it as a deliberate tradeoff on a specific surface, not a default to apply everywhere. ## What the built-in 405 usually carries When a framework does produce the method-mismatch response, it typically fills in the header enumerating the methods it does have registered for that path, because the route table already holds exactly that set. This is why the built-in response is often more accurate than a hand-written one: it is generated from the registrations rather than from a comment somebody forgot to update. ## The two defaults that skew what you observe 1. **Automatic `OPTIONS`.** Many frameworks answer that method themselves from the route table rather than dispatching it, so it rarely reaches the mismatch branch. 2. **`HEAD` derived from `GET`.** Where a framework runs the registered `GET` handler and discards the body, a `HEAD` request against a `GET`-only route succeeds instead of producing a mismatch. Both are convenience defaults, both are usually switchable, and both explain "why did *that* method not give me the response I expected". ## Diagnosing it in practice The question a working engineer actually faces is "my client gets 404 for a path I am certain I registered". The ordered checks: - Did you register it for the method the client is using? A mismatch reported as `404` is the classic cause. - Is the path registered under a prefix or group that the request is not entering? - Did something in front of the application answer before it arrived - is there an access-log line at all? If the framework reports mismatches as `404`, note that you can usually change it, and that changing it is a disclosure decision as much as an ergonomics one. ## Talking about it in an interview Say what is true across frameworks rather than asserting one behaviour: the distinction exists only if the router indexes path and method separately, `405` is the common default where it does, `404` appears both as a structural consequence and as a deliberate choice, and auto-handled methods mean the observed behaviour is not a clean read of the route table.