405 Method Not Allowed : causes et corrections

Ce que signifie 405 Method Not Allowed

La RFC 9110 exige qu'une réponse 405 inclue un en-tête Allow listant les méthodes que la ressource supporte réellement. Cet en-tête est tout le diagnostic en une ligne : si une requête vers /api/users renvoie 405 avec Allow: GET, HEAD, la route existe et fonctionne bien pour la lecture, elle n'a simplement jamais eu de gestionnaire câblé pour la méthode que vous avez envoyée.

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

Comment l'erreur apparaît

Les navigateurs affichent une page d'erreur générique pour un 405 renvoyé à une navigation normale, puisque ce n'est pas un cas pour lequel ils ont une gestion particulière. Il est bien plus courant de rencontrer un 405 dans un onglet réseau, un appel AJAX échoué, ou un échec de préflight CORS dans la console, car la plupart des 405 viennent de requêtes scriptées plutôt que de liens cliqués. Depuis la ligne de commande, la méthode et l'en-tête Allow racontent toute l'histoire :

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

Ce qui provoque un 405 Method Not Allowed

• Un POST vers un fichier statique. Une requête pour un fichier réel sur disque, comme un PDF ou une image, servi par un serveur web qui ne répond qu'à GET et HEAD pour le contenu statique.
• L'appel d'une route qui ne définit que certaines méthodes. Une route de framework enregistrée pour GET seul renvoie 405 pour chaque autre verbe, par conception, plutôt que 404.
• Une requête OPTIONS de préflight CORS rejetée. Les navigateurs envoient une requête OPTIONS automatique avant certains appels cross-origin, et un serveur ou une passerelle qui n'a aucun gestionnaire pour OPTIONS sur ce chemin répond 405, ce qui se manifeste ensuite dans le navigateur comme une requête cross-origin bloquée plutôt qu'un 405 clair.
• nginx servant un bloc location destiné aux fichiers statiques. Un bloc location utilisant try_files contre le système de fichiers sans proxy_pass renverra 405 sur POST, puisque le service de fichiers statiques dans nginx n'implémente que GET, HEAD, et par défaut un ensemble de méthodes limité.
• Les restrictions de verbes de WebDAV et IIS. IIS et certains serveurs WebDAV explicitement configurés mettent sur liste d'autorisation les verbes par chemin, et une méthode en dehors de cette liste, y compris des méthodes personnalisées comme PROPFIND, obtient 405 même si la route générale fonctionne par ailleurs.
• Une mauvaise configuration de route de framework. Une route destinée à accepter à la fois GET et POST mais enregistrée pour un seul, souvent après un refactoring qui a scindé un gestionnaire sans mettre à jour la déclaration de route.
• Une liste d'autorisation de méthodes d'un équilibreur de charge ou d'une passerelle d'API. Certaines passerelles restreignent les méthodes autorisées par route indépendamment de l'application, et l'application ne voit même jamais la requête rejetée.

Comment savoir de qui vient la faute

Un 405 est presque toujours un problème de configuration ou de code côté serveur plutôt que quelque chose causé par un visiteur, puisque les navigateurs et les liens normaux n'envoient pas de méthodes arbitraires de leur propre initiative. Si une page fonctionne globalement mais qu'une action, comme une soumission de formulaire ou un appel d'API depuis du JavaScript côté client, échoue avec 405, vérifiez si la méthode de cette requête précise correspond à ce que le point de terminaison attend. Si c'est le cas et que l'erreur est nouvelle, le moyen le plus rapide de confirmer qu'une route ou une configuration de proxy s'est cassée est de lancer une vérification HTTP qui envoie exactement la méthode que votre application utilise et de comparer le résultat autour d'un déploiement récent.

Comment corriger un 405 Method Not Allowed

Si vous êtes visiteur

1. Rechargez et réessayez l'action, puisqu'un 405 venant d'une soumission de formulaire peut parfois suivre une page qui a chargé une version en cache obsolète du formulaire pointant vers le mauvais point de terminaison.
2. Videz le cache du navigateur pour le site si le problème persiste, au cas où un service worker périmé ou une réponse en cache rejouerait une vieille requête désormais incompatible.
3. Signalez-le au site, puisque c'est un problème de configuration de leur côté dans presque tous les cas ; il n'y a pas de correction côté client pour un serveur qui n'accepte réellement pas la méthode.

Si vous gérez le site

1. Lisez l'en-tête Allow sur votre propre réponse 405 pour confirmer exactement quelles méthodes le serveur pense valides pour ce chemin, puis comparez cela à ce que le client envoie réellement.
2. Ajoutez la méthode manquante à la route. Sur la plupart des frameworks, c'est une déclaration de route d'une seule ligne ; la correction se situe rarement dans la logique applicative une fois que vous savez quel verbe manque.
3. Gérez OPTIONS explicitement pour les routes activées pour CORS. Soit laissez le middleware CORS de votre framework répondre automatiquement aux requêtes de préflight, soit ajoutez un gestionnaire qui renvoie les bons en-têtes Allow et Access-Control-Allow-Methods.
4. Corrigez le bloc location de nginx si un bloc de fichiers statiques capture une route qui a besoin d'un backend. Un exemple minimal qui redirige POST vers un proxy au lieu de le servir comme un fichier :

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

5. Vérifiez séparément les listes d'autorisation de méthodes de la passerelle et de l'équilibreur de charge de celles de l'application, puisqu'une requête peut être rejetée avant même d'atteindre votre code, et les journaux applicatifs ne montreront rien pour elle.

Comment prévenir un 405 silencieux après un déploiement

Une route qui perd une méthode pendant un refactoring, ou une règle de proxy qui commence à intercepter un chemin qu'elle n'interceptait pas avant, ne lèvera d'exception nulle part, elle répondra simplement une réponse HTTP fausse-mais-valide. Une vérification HTTP programmée avec une assertion sur le code de statut, envoyée avec exactement la méthode dont votre intégration dépend, détecte cette régression juste après le déploiement qui l'a causée plutôt qu'après que les utilisateurs signalent des formulaires cassés. Pour les points de terminaison d'API en particulier, une surveillance d'API qui vérifie à la fois la méthode et le corps de la réponse confirme que la route non seulement accepte la requête mais se comporte encore correctement.

Erreurs associées

Voir 404 Not Found pour un chemin qui n'existe pas du tout, par opposition à un qui existe mais rejette la méthode, l'aperçu des 4xx pour la famille complète, et 401 Unauthorized et 422 Unprocessable Content ailleurs dans ce lot.

Questions fréquentes

Quelle est la différence entre 404 et 405 ?

404 signifie que rien n'existe à ce chemin pour aucune méthode. 405 signifie que le chemin existe et fonctionne pour au moins une méthode, simplement pas celle que vous avez utilisée, et l'en-tête Allow confirme lesquelles sont valides.

Pourquoi une requête CORS échoue-t-elle avec quelque chose qui ressemble à un 405 ?

Les navigateurs envoient un préflight OPTIONS automatique avant de nombreuses requêtes cross-origin. Si le serveur n'a aucun gestionnaire pour OPTIONS sur cette route, il répond 405, et le navigateur le rapporte comme un échec CORS dans la console plutôt que d'afficher directement le code de statut brut.

Le 405 est-il parfois la réponse correcte qu'une API doit envoyer délibérément ?

Oui. Si une ressource ne supporte réellement que la lecture, renvoyer 405 pour un PUT ou un DELETE contre elle est un comportement REST correct, et c'est plus informatif pour l'appelant qu'un 404 générique ne le serait.

Un pare-feu ou un WAF peut-il causer un 405 ?

C'est moins courant qu'une mauvaise configuration d'application ou de proxy, mais certains jeux de règles WAF restreignent les méthodes autorisées par chemin et répondront 405 ou un blocage similaire avant même que la requête n'atteigne l'origine.

Pourquoi l'en-tête Allow liste-t-il parfois des méthodes qui échouent quand même ?

L'en-tête Allow reflète ce pour quoi la route est enregistrée, pas nécessairement ce qui est entièrement implémenté. Une méthode peut être déclarée et quand même renvoyer une erreur pour d'autres raisons, comme une autorisation manquante, une fois qu'elle passe la vérification de méthode.