HTTP Statuscode 405: Method Not Allowed

Der HTTP Statuscode 405 sagt etwas sehr Genaues: Die Adresse existiert, der Server versteht die Methode — aber für diese Adresse ist sie nicht vorgesehen. Es ist eine Aussage über die Kombination aus beidem, nicht über eines von beidem allein.

Das macht 405 zu einem der informativeren Fehlercodes. Vorausgesetzt, der Server hält sich an seine Pflicht.

Die Pflicht zum Allow-Header#

RFC 9110 lässt hier keinen Spielraum: Eine 405-Antwort muss einen Allow-Header enthalten, der die für diese Adresse unterstützten Methoden auflistet.

`` HTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS Content-Type: text/plain ``

Der Grund ist praktischer Natur: Ohne diese Zeile bleibt dem Aufrufer nur Raten. Mit ihr steht die Antwort auf die naheliegende Folgefrage bereits in der Antwort. Fehlt der Header, ist das ein Fehler der Anwendung oder des Frameworks — und zugleich der erste Hinweis darauf, wo der 405 herkommt. Server, die selbst antworten, senden ihn in der Regel korrekt; selbstgebaute Fehlerbehandlungen in Anwendungen lassen ihn regelmäßig weg.

Eine leere Liste (Allow: ohne Wert) ist zulässig und bedeutet: für diese Adresse ist derzeit keine Methode erlaubt.

Abgrenzung zu 404 und 501#

Die drei Codes werden ständig verwechselt, obwohl sie drei verschiedene Dinge behaupten.

404 Not Found. Der Server hat keine Darstellung für diese Adresse und sagt nichts über Methoden. Wer einen Tippfehler im Pfad hat, bekommt 404, egal mit welcher Methode er anklopft.

405 Method Not Allowed. Die Adresse ist bekannt, die Methode wird für sie nicht unterstützt. DELETE auf eine Übersichtsseite ist der Lehrbuchfall.

501 Not Implemented. Der Server unterstützt die Methode überhaupt nicht, für keine Adresse. Das betrifft Methoden, die er gar nicht kennt oder nicht umsetzen kann — nicht solche, die er kennt und hier nur nicht anbietet.

Dazu kommt der Sonderfall 403 Forbidden, der oft fälschlich statt 405 gesendet wird. 403 ist eine Aussage über die Berechtigung, nicht über die Methode. Wer PUT pauschal in der Serverkonfiguration sperrt und dafür 403 zurückgibt, produziert eine irreführende Antwort.

Ein Detail mit Folgen: 405 gehört nach RFC 9110 zu den Statuscodes, die standardmäßig zwischengespeichert werden dürfen. Wird eine Route nachträglich um POST erweitert, kann ein zwischengeschalteter Cache die alte Ablehnung noch eine Weile ausliefern. Das erklärt „Ich habe es doch repariert"-Momente, die keine sind.

Die vier üblichen Ursachen#

1. POST auf eine statische Datei. Ein Formular ohne action-Attribut schickt seine Daten an die eigene Adresse. Ist das eine ausgelieferte HTML-Datei, kann der Webserver damit nichts anfangen: Für statische Dateien kennt er GET, HEAD und OPTIONS, sonst nichts. Das ist der häufigste 405 überhaupt und fällt fast immer beim Umstieg von einem dynamischen auf ein statisch ausgeliefertes Frontend auf.

2. Route existiert, Methode fehlt. Fast alle Web-Frameworks trennen Pfad und Methode. Ist /api/nutzer nur für GET registriert, beantworten sie ein POST korrekt mit 405 statt mit 404 — die Adresse gibt es ja. Meist fehlt schlicht die zweite Registrierung, oder die Route wurde in einer Gruppe angelegt, die nur lesende Methoden zulässt.

3. Methoden in der Serverkonfiguration gesperrt. Sehr verbreitet sind Blöcke, die PUT, DELETE, PATCH oder TRACE global abweisen — oft aus einer alten Sicherheitsempfehlung übernommen und nie wieder angefasst. In einer .htaccess sieht das etwa so aus:

``apache <LimitExcept GET POST HEAD> Require all denied </LimitExcept> ``

Solche Zeilen sammeln sich über Jahre an. Wo sie herkommen und wie eine aufgeräumte Datei aussieht, behandelt der Artikel zur Standard-.htaccess von WordPress.

4. Ein Zwischenglied blockiert. Reverse Proxy, CDN oder Web Application Firewall filtern Methoden, bevor die Anwendung sie sieht. Besonders unangenehm ist der Fall der abgewiesenen OPTIONS-Anfrage: Der Vorabruf einer Cross-Origin-Anfrage scheitert dann mit 405, und im Browser erscheint stattdessen eine CORS-Fehlermeldung, die auf eine ganz andere Ursache zeigt.

Eingrenzen in drei Aufrufen#

Zuerst fragen, was erlaubt ist:

``bash curl -sI -X OPTIONS https://beispiel.de/api/nutzer curl -sI -X POST https://beispiel.de/api/nutzer curl -sI https://beispiel.de/api/nutzer ``

Antwortet der dritte Aufruf mit 200 und der zweite mit 405, existiert die Adresse und die Methode fehlt. Antworten alle drei mit 404, ist der Pfad falsch. Kommt 405 ohne Allow-Zeile, beantwortet die Anwendung den Fehler selbst — dann liegt die Ursache dort und nicht im Webserver.

Der Server, der geantwortet hat, steht meist in der Server-Kopfzeile. Weicht sie von der erwarteten ab, hat ein Zwischenglied abgefangen, und die Suche beginnt dort.

Wenn 405 dagegen auf Adressen auftaucht, die aus dem eigenen Auftritt verlinkt sind, ist es weniger ein Serverproblem als ein Wartungsproblem: Tote Links finden zeigt, wie man solche Verweise systematisch aufspürt.