405 Method Not Allowed: oorzaken en oplossingen

Wat 405 Method Not Allowed betekent

RFC 9110 vereist dat een 405-antwoord een Allow-header bevat die de methoden opsomt die de resource daadwerkelijk ondersteunt. Die header is de hele diagnose in één regel: geeft een verzoek naar /api/users 405 terug met Allow: GET, HEAD, dan bestaat de route en werkt hij prima voor lezen, er was alleen nooit een handler aangesloten voor welke methode u ook stuurde.

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Hoe de fout verschijnt

Browsers tonen een generieke foutpagina voor een 405 die wordt teruggegeven bij een normale navigatie, aangezien dit geen geval is waar ze speciale afhandeling voor hebben. Het is veel gebruikelijker om een 405 tegen te komen in een netwerktabblad, een mislukte AJAX-aanroep, of een mislukte CORS-preflight in de console, omdat de meeste 405's afkomstig zijn van gescripte verzoeken in plaats van aangeklikte links. Vanaf de commandoregel vertellen de methode en de Allow-header het hele verhaal:

curl -i -X POST https://example.com/downloads/report.pdf
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Wat een 405 Method Not Allowed veroorzaakt

• POSTen naar een statisch bestand. Een verzoek voor een echt bestand op schijf, zoals een PDF of een afbeelding, geserveerd door een webserver die alleen GET en HEAD beantwoordt voor statische inhoud.
• Een route aanroepen die slechts sommige methoden definieert. Een frameworkroute die alleen voor GET is geregistreerd geeft per ontwerp 405 terug voor elk ander werkwoord, in plaats van 404.
• Een CORS-preflight-OPTIONS-verzoek dat wordt geweigerd. Browsers sturen automatisch een OPTIONS-verzoek voordat bepaalde cross-origin-aanroepen plaatsvinden, en een server of gateway zonder handler voor OPTIONS op dat pad antwoordt 405, wat vervolgens in de browser naar boven komt als een geblokkeerd cross-origin-verzoek in plaats van een duidelijke 405.
• nginx die een locatieblock serveert bedoeld voor statische bestanden. Een location-block dat try_files gebruikt tegen het bestandssysteem zonder proxy_pass geeft 405 bij POST, aangezien het serveren van statische bestanden in nginx alleen GET, HEAD, en standaard een beperkte methodeset implementeert.
• WebDAV- en IIS-werkwoordbeperkingen. IIS en sommige WebDAV-ingeschakelde servers zetten werkwoorden expliciet per pad op de allowlist, en een methode buiten die lijst, ook aangepaste zoals PROPFIND, krijgt 405 zelfs als de algemene route verder werkt.
• Verkeerd geconfigureerde frameworkroute. Een route bedoeld om zowel GET als POST te accepteren maar slechts voor één geregistreerd, vaak na een refactor die een handler splitste zonder de routedeclaratie bij te werken.
• Een allowlist voor methoden op een loadbalancer of API-gateway. Sommige gateways beperken toegestane methoden per route los van de applicatie, en de app krijgt het geweigerde verzoek nooit eens te zien.

Hoe u vaststelt wiens fout het is

Een 405 is vrijwel altijd een configuratie- of codeprobleem aan de serverkant in plaats van iets wat een bezoeker veroorzaakte, aangezien browsers en normale links niet uit zichzelf willekeurige methoden versturen. Werkt een pagina grotendeels maar mislukt één actie, zoals een formulierinzending of een API-aanroep vanuit client-side JavaScript, met 405, controleer dan of de methode van dat specifieke verzoek overeenkomt met wat het endpoint verwacht. Is dat zo en is de fout nieuw, dan is de snelste manier om te bevestigen dat een route- of proxyconfiguratie kapot is gegaan een HTTP-controle uit te voeren die precies de methode stuurt die uw applicatie gebruikt en het resultaat te vergelijken over een recente deployment heen.

Hoe u een 405 Method Not Allowed oplost

Bent u de bezoeker

1. Laad opnieuw en probeer de actie opnieuw, aangezien een 405 bij een formulierinzending soms kan volgen op een pagina die een verouderde gecachete versie van het formulier laadde die naar het verkeerde endpoint wees.
2. Wis de browsercache voor de site als het probleem aanhoudt, voor het geval een verouderde service worker of gecachet antwoord een oud, nu incompatibel verzoek herhaalt.
3. Meld het bij de site, aangezien dit in bijna elk geval een configuratieprobleem aan hun kant is; er is geen client-side oplossing voor een server die de methode echt niet accepteert.

Beheert u de site

1. Lees de Allow-header op uw eigen 405-antwoord om precies te bevestigen welke methoden de server voor dat pad geldig acht, en vergelijk dat dan met wat de client daadwerkelijk verstuurt.
2. Voeg de ontbrekende methode toe aan de route. Op de meeste frameworks is dit een routedeclaratie van één regel; de oplossing zit zelden in applicatielogica zodra u weet welk werkwoord ontbreekt.
3. Behandel OPTIONS expliciet voor CORS-ingeschakelde routes. Laat ofwel de CORS-middleware van uw framework preflight-verzoeken automatisch beantwoorden, ofwel voeg een handler toe die de juiste Allow- en Access-Control-Allow-Methods-headers teruggeeft.
4. Herstel het nginx-locatieblock als een block voor statische bestanden een route onderschept die een backend nodig heeft. Een minimaal voorbeeld dat POST doorproxyt in plaats van het als bestand te serveren:

   location /api/ {
       proxy_pass http://backend;
   }

5. Controleer allowlists voor methoden op gateway en loadbalancer los van de applicatie, aangezien een verzoek geweigerd kan worden voordat het uw code ooit bereikt, en de applicatielogs er niets over zullen tonen.

Hoe u een stille 405 na een deployment voorkomt

Een route die tijdens een refactor een methode verliest, of een proxyregel die een pad begint te onderscheppen dat hij eerder niet onderschepte, gooit nergens een uitzondering, hij geeft gewoon een verkeerd-maar-geldig HTTP-antwoord terug. Een geplande HTTP-controle met een assertie op de statuscode, verstuurd met precies de methode waar uw integratie op leunt, vangt die regressie meteen na de deployment die hem veroorzaakte, in plaats van nadat gebruikers kapotte formulieren melden. Voor API-endpoints specifiek bevestigt API-monitoring die zowel de methode als de responsbody controleert dat de route het verzoek niet alleen accepteert maar zich ook nog steeds correct gedraagt.

Gerelateerde fouten

Zie 404 Not Found voor een pad dat helemaal niet bestaat, in tegenstelling tot een pad dat bestaat maar de methode weigert, het 4xx-overzicht voor de volledige familie, en 401 Unauthorized en 422 Unprocessable Content elders in deze reeks.

Veelgestelde vragen

Wat is het verschil tussen 404 en 405?

404 betekent dat er op dat pad niets bestaat voor welke methode dan ook. 405 betekent dat het pad bestaat en werkt voor ten minste één methode, alleen niet degene die u gebruikte, en de Allow-header bevestigt welke methoden geldig zijn.

Waarom mislukt een CORS-verzoek met iets dat op een 405 lijkt?

Browsers sturen automatisch een OPTIONS-preflight voor veel cross-origin-verzoeken. Heeft de server geen handler voor OPTIONS op die route, dan antwoordt hij 405, en de browser rapporteert het in de console als een CORS-storing in plaats van de rauwe statuscode direct te tonen.

Is 405 ooit het correcte antwoord dat een API opzettelijk stuurt?

Ja. Ondersteunt een resource echt alleen lezen, dan is 405 teruggeven bij een PUT of DELETE ertegen correct REST-gedrag, en het is informatiever voor de aanroeper dan een generieke 404 zou zijn.

Kan een firewall of WAF een 405 veroorzaken?

Het komt minder vaak voor dan een verkeerde configuratie van applicatie of proxy, maar sommige WAF-regelsets beperken toegestane methoden per pad en beantwoorden met 405 of een vergelijkbare blokkade voordat het verzoek de origin ook maar bereikt.

Waarom vermeldt de Allow-header soms methoden die toch falen?

De Allow-header weerspiegelt waarvoor de route geregistreerd is, niet noodzakelijk wat volledig geïmplementeerd is. Een methode kan gedeclareerd zijn en toch een fout teruggeven om andere redenen, zoals ontbrekende autorisatie, zodra hij de methodecontrole passeert.