HTTP 405 Method Not Allowed : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un outil de monitoring ou un checker reçoit 405 Method Not Allowed.
• Une méthode HTTP échoue alors qu’une autre méthode pour la même route peut fonctionner.
• Le problème peut concerner une URL, un schéma de route, un client ou un déploiement, plutôt que l’ensemble du site.
• La réponse peut inclure un en-tête Allow listant les méthodes autorisées.
• D’autres en-têtes peuvent révéler des informations sur les redirections, le cache, l’authentification, le proxy, le CDN ou le serveur.
• Puisqu’une réponse HTTP a été reçue, la résolution DNS et la négociation TLS peuvent déjà avoir abouti, mais cela ne prouve pas que l’application ou la route est correctement configurée.

Causes principales, classées par probabilité

Causes courantes

1. La méthode n’est pas prise en charge par la route. Le endpoint peut accepter GET mais refuser POST, ou accepter POST mais refuser une méthode de mise à jour telle que PUT ou PATCH.
2. Les règles de routage ou du serveur web refusent la méthode. Une route, un virtual host ou une règle serveur peut empêcher la requête d’atteindre le handler prévu.
3. Un reverse proxy, un CDN ou un WAF renvoie la réponse en premier. Un intermédiaire peut appliquer des restrictions de méthode ou router la requête différemment de l’origine.
4. La requête ne correspond pas au contrat de l’application. Le chemin, le slash final, le type de contenu, l’hôte, l’état d’authentification ou d’autres détails de la requête peuvent sélectionner une autre route ou règle de validation.
5. Un déploiement ou une modification de configuration récente a introduit une incompatibilité. Les routes de l’application, les règles du proxy, les méthodes autorisées et le comportement du cache peuvent ne plus être cohérents.
6. Une règle intentionnelle ou une conception de endpoint. Certaines ressources refusent délibérément les méthodes considérées comme dangereuses, non prises en charge ou extérieures à leur interface documentée.

Le code de statut seul ne permet pas d’identifier la couche ou la règle à l’origine de la réponse. Confirmez la méthode, les en-têtes, les journaux et les modifications récentes avant de modifier le système.

Comment corriger le problème

Si vous êtes visiteur ou utilisateur d’une API

1. Confirmez l’URL exacte et vérifiez que le client envoie la méthode prévue. Une requête saisie dans la barre d’adresse d’un navigateur utilise normalement GET, tandis qu’un client API peut utiliser POST, PUT, PATCH, DELETE ou une autre méthode.
2. Vérifiez les en-têtes de réponse pour rechercher un en-tête Allow ainsi que des informations sur les redirections, l’authentification, le cache ou le proxy. Ne considérez pas une autre méthode comme une solution de contournement valide, sauf si la documentation du site ou de l’API indique qu’elle est prise en charge.
3. Si le endpoint nécessite un compte, connectez-vous via la procédure habituelle et réessayez sans exposer vos identifiants dans une demande d’assistance.
4. Évitez les tentatives répétées lorsque le service signale également des limites de débit, des délais d’attente ou des signes de surcharge.
5. Si le problème persiste, transmettez au propriétaire du site l’URL, la méthode, l’horodatage, le code de statut et les en-têtes pertinents après suppression des données sensibles. Ne partagez pas de mots de passe, cookies, jetons d’autorisation ou secrets d’API.

Si vous possédez ou gérez le site

1. Créez une reproduction minimale. Notez la méthode exacte, l’URL, l’hôte, le chemin de requête, le statut et les en-têtes de réponse pertinents. Ne conservez le corps de la requête que s’il ne contient aucun secret ni donnée personnelle.
2. Vérifiez si la réponse est intentionnelle. Comparez la requête avec le contrat de la route ou de l’API. Déterminez si la ressource est censée prendre en charge cette méthode et si un en-tête Allow indique les méthodes acceptées.
3. Identifiez la couche qui répond. Utilisez les en-têtes de réponse, les identifiants de requête et les horodatages pour déterminer si la réponse provient de l’application, du serveur web, du reverse proxy, du CDN ou du WAF. Une réponse générée par un proxy peut ne jamais atteindre l’origine.
4. Examinez les journaux correspondants. Recherchez, dans la couche identifiée et, si possible, dans la couche en amont, le même horodatage, chemin, méthode et identifiant de requête. Cherchez les incompatibilités de route, les filtres de méthode, les requêtes amont refusées et les modifications récentes de règles.
5. Comparez les modifications récentes. Examinez les déploiements, les définitions de routes, les règles du serveur web, le comportement du proxy ou du CDN, la configuration de l’authentification et les règles du WAF. Comparez la méthode en échec avec une méthode connue comme prise en charge pour la même route.
6. Appliquez la correction autorisée la plus ciblée. Modifiez uniquement la route ou la règle qui doit prendre en charge la méthode. Ne désactivez pas globalement l’authentification, les protections du WAF ou les restrictions de méthode pour faire disparaître l’erreur.
7. Retestez en toute sécurité. Répétez la même requête dans un environnement hors production lorsque c’est possible, puis testez la route de production concernée dans le cadre de la procédure de modification approuvée. Vérifiez que les méthodes non prises en charge restent refusées et que les routes associées renvoient toujours leurs codes de statut prévus.
8. Vérifiez les caches et les intermédiaires. Si le comportement diffère selon les clients ou les emplacements, vérifiez si un proxy ou un CDN a mis la réponse en cache ou applique une règle distincte. Purgez le cache ou modifiez son comportement uniquement selon la procédure opérationnelle habituelle du service.

Prévention et vérification du correctif

• Définissez et documentez les méthodes prises en charge pour les routes web et endpoints d’API importants.
• Testez les méthodes représentatives des routes critiques après toute modification de l’application, du serveur, du proxy, du CDN ou du WAF.
• Surveillez les taux de codes de statut par route et par méthode au lieu de regrouper toutes les réponses 4xx.
• Gérez le routage, les restrictions de méthode, l’authentification et la configuration du proxy dans un système de contrôle de version.
• Conservez les identifiants de requête et les journaux des couches intermédiaires et d’origine suffisamment longtemps pour corréler les erreurs.
• Documentez les réponses 405 intentionnelles afin que les équipes d’assistance et de monitoring puissent distinguer le comportement attendu des régressions.
• Évitez les autorisations de méthode trop larges ; n’autorisez que les méthodes nécessaires à chaque ressource et au contrat de l’application.

Questions fréquentes