405 Method Not Allowed: Ursachen und Lösungen
Ein 405 Method Not Allowed bedeutet, die Ressource existiert, und der Server hat die Anfrage verstanden, akzeptiert aber die HTTP-Methode nicht, mit der Sie sie angesteuert haben. Eine Nur-GET-Seite kann kein POST erhalten, und ein für POST gebauter Formular-Endpunkt kann nicht mit PUT abgerufen werden, und der Server lehnt allein aus diesem Grund ab.
Was 405 Method Not Allowed bedeutet
RFC 9110 verlangt, dass eine 405-Antwort einen Allow-Header trägt, der die Methoden auflistet, die die Ressource tatsächlich unterstützt. Dieser Header ist die gesamte Diagnose in einer Zeile: Gibt eine Anfrage an /api/users 405 mit Allow: GET, HEAD zurück, existiert die Route und funktioniert einwandfrei zum Lesen, es war nur nie ein Handler für die von Ihnen gesendete Methode verdrahtet.
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Wie sich der Fehler zeigt
Browser zeigen eine generische Fehlerseite für einen 405, der bei normaler Navigation zurückkommt, da das kein Fall ist, für den sie eine spezielle Behandlung haben. Weit häufiger begegnet man einem 405 in einem Netzwerk-Tab, einem gescheiterten AJAX-Aufruf, oder einem CORS-Preflight-Fehlschlag in der Konsole, da die meisten 405er von skriptgesteuerten Anfragen kommen statt von angeklickten Links. Von der Kommandozeile aus erzählen Methode und Allow-Header die ganze Geschichte:
curl -i -X POST https://example.com/downloads/report.pdf
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Was einen 405 Method Not Allowed verursacht
- POST an eine statische Datei. Eine Anfrage für eine tatsächliche Datei auf der Platte, etwa ein PDF oder ein Bild, bedient von einem Webserver, der für statische Inhalte nur GET und HEAD beantwortet.
- Aufruf einer Route, die nur manche Methoden definiert. Eine allein für GET registrierte Framework-Route gibt für jedes andere Verb per Design 405 zurück, statt 404.
- Eine abgelehnte CORS-Preflight-OPTIONS-Anfrage. Browser senden vor bestimmten Cross-Origin-Aufrufen automatisch eine
OPTIONS-Anfrage, und ein Server oder Gateway ohne Handler für OPTIONS auf diesem Pfad antwortet mit 405, was dann im Browser als blockierte Cross-Origin-Anfrage erscheint statt als klarer 405. - nginx bedient einen für statische Dateien gedachten Location-Block. Ein
location-Block, der mittry_filesgegen das Dateisystem arbeitet, ohne proxy_pass, gibt bei POST 405 zurück, da statisches Dateiserving in nginx nur GET, HEAD, und standardmäßig eine begrenzte Methodenmenge implementiert. - WebDAV- und IIS-Verb-Beschränkungen. IIS und manche WebDAV-fähigen Server erlauben Verben pro Pfad ausdrücklich als Positivliste, und eine Methode außerhalb dieser Liste, einschließlich eigener wie PROPFIND, bekommt 405, selbst wenn die allgemeine Route sonst funktioniert.
- Falsch konfigurierte Framework-Route. Eine Route, die sowohl GET als auch POST akzeptieren soll, aber nur für eine registriert ist, oft nach einem Refactoring, das einen Handler aufgeteilt hat, ohne die Routen-Deklaration zu aktualisieren.
- Eine Methoden-Positivliste an Load Balancer oder API-Gateway. Manche Gateways beschränken erlaubte Methoden pro Route unabhängig von der Anwendung, und die App bekommt die abgelehnte Anfrage nie zu Gesicht.
So finden Sie heraus, wer schuld ist
Ein 405 ist fast immer ein serverseitiges Konfigurations- oder Code-Problem statt etwas, das ein Besucher verursacht hat, da Browser und normale Links nicht von sich aus beliebige Methoden senden. Funktioniert eine Seite größtenteils, scheitert aber eine Aktion wie ein Formular-Absenden oder ein API-Aufruf aus clientseitigem JavaScript mit 405, prüfen Sie, ob die Methode dieser konkreten Anfrage dem entspricht, was der Endpunkt erwartet. Tut sie das, und der Fehler ist neu, ist der schnellste Weg zu bestätigen, dass eine Routen- oder Proxy-Konfiguration kaputtgegangen ist, eine HTTP-Prüfung auszuführen, die genau die Methode sendet, die Ihre Anwendung nutzt, und das Ergebnis über einen kürzlichen Deploy hinweg zu vergleichen.
So beheben Sie einen 405 Method Not Allowed
Wenn Sie Besucher sind
- Laden Sie neu und versuchen Sie die Aktion erneut, da ein 405 bei einem Formular-Absenden manchmal einer Seite folgt, die eine veraltete zwischengespeicherte Version des Formulars geladen hat, das auf den falschen Endpunkt zeigt.
- Leeren Sie den Browser-Cache für die Website, falls das Problem bestehen bleibt, falls ein veralteter Service Worker oder eine zwischengespeicherte Antwort eine alte, jetzt inkompatible Anfrage wiederholt.
- Melden Sie es der Website, da das fast immer ein Konfigurationsproblem auf deren Seite ist; es gibt keine clientseitige Lösung für einen Server, der die Methode tatsächlich nicht akzeptiert.
Wenn Sie die Website betreiben
- Lesen Sie den
Allow-Header Ihrer eigenen 405-Antwort, um genau zu bestätigen, welche Methoden der Server für diesen Pfad für gültig hält, und vergleichen Sie das mit dem, was der Client tatsächlich sendet. - Fügen Sie die fehlende Methode zur Route hinzu. Bei den meisten Frameworks ist das eine einzeilige Routen-Deklaration; die Lösung liegt selten in der Anwendungslogik, sobald Sie wissen, welches Verb fehlt.
- Behandeln Sie OPTIONS ausdrücklich für CORS-fähige Routen. Lassen Sie entweder die CORS-Middleware Ihres Frameworks Preflight-Anfragen automatisch beantworten, oder fügen Sie einen Handler hinzu, der die korrekten
Allow- undAccess-Control-Allow-Methods-Header zurückgibt. - Beheben Sie den nginx-Location-Block, falls ein Block für statische Dateien eine Route abfängt, die ein Backend braucht. Ein minimales Beispiel, das POST stattdessen durchreicht, statt es als Datei zu bedienen:
location /api/ { proxy_pass http://backend; } - Prüfen Sie Gateway- und Load-Balancer-Methoden-Positivlisten getrennt von der Anwendung, da eine Anfrage abgelehnt werden kann, bevor sie überhaupt Ihren Code erreicht, und Anwendungslogs dann nichts dazu zeigen.
So verhindern Sie einen stillen 405 nach einem Deploy
Eine Route, die bei einem Refactoring eine Methode verliert, oder eine Proxy-Regel, die anfängt, einen Pfad abzufangen, den sie vorher nicht abgefangen hat, wirft nirgendwo eine Ausnahme, sie beantwortet einfach eine falsch-aber-gültige HTTP-Antwort. Eine geplante HTTP-Prüfung mit einer Zusicherung auf den Statuscode, gesendet mit genau der Methode, auf die Ihre Integration angewiesen ist, erkennt diese Regression direkt nach dem Deploy, der sie verursacht hat, statt nachdem Nutzer kaputte Formulare melden. Für API-Endpunkte im Besonderen bestätigt API-Monitoring, das sowohl Methode als auch Antwort-Body prüft, dass die Route die Anfrage nicht nur akzeptiert, sondern sich auch weiterhin korrekt verhält.
Verwandte Fehler
Siehe 404 Not Found für einen Pfad, der überhaupt nicht existiert, im Gegensatz zu einem, der existiert, aber die Methode ablehnt, die 4xx-Übersicht für die gesamte Familie, und 401 Unauthorized und 422 Unprocessable Content anderswo in dieser Gruppe.
Häufig gestellte Fragen
Was ist der Unterschied zwischen 404 und 405?
404 bedeutet, für diesen Pfad existiert nichts, für keine Methode. 405 bedeutet, der Pfad existiert und funktioniert für mindestens eine Methode, nur nicht die von Ihnen genutzte, und der Allow-Header bestätigt, welche Methoden gültig sind.
Warum scheitert eine CORS-Anfrage mit etwas, das wie ein 405 aussieht?
Browser senden vor vielen Cross-Origin-Anfragen automatisch ein OPTIONS-Preflight. Hat der Server keinen Handler für OPTIONS auf dieser Route, antwortet er mit 405, und der Browser meldet es in der Konsole als CORS-Fehlschlag, statt den rohen Statuscode direkt zu zeigen.
Ist 405 jemals die korrekte Antwort, die eine API absichtlich sendet?
Ja. Unterstützt eine Ressource tatsächlich nur das Lesen, ist 405 für ein PUT oder DELETE dagegen korrektes REST-Verhalten, und es ist für den Aufrufer informativer als ein generischer 404.
Kann eine Firewall oder WAF einen 405 verursachen?
Das ist seltener als eine Anwendungs- oder Proxy-Fehlkonfiguration, aber manche WAF-Regelwerke beschränken erlaubte Methoden pro Pfad und antworten mit 405 oder einer ähnlichen Blockierung, bevor die Anfrage den Ursprung überhaupt erreicht.
Warum listet der Allow-Header manchmal Methoden, die trotzdem scheitern?
Der Allow-Header spiegelt wider, wofür die Route registriert ist, nicht zwingend, was vollständig implementiert ist. Eine Methode kann deklariert sein und trotzdem aus anderen Gründen einen Fehler zurückgeben, etwa fehlende Autorisierung, sobald sie die Methodenprüfung besteht.