Erreur 405 Method Not Allowed : signification et solutions

Qu'est-ce que l'erreur 405 Method Not Allowed ?

405 Method Not Allowed est un code de statut HTTP qui signifie que le serveur connaît l'adresse demandée, mais n'autorise pas la méthode utilisée par votre requête. La RFC 9110 (section 15.5.6) la définit comme une méthode « known by the origin server but not supported by the target resource », c'est-à-dire connue du serveur d'origine mais non prise en charge par la ressource ciblée.

Chaque requête HTTP a une méthode : GET pour lire une page, POST pour envoyer un formulaire ou créer quelque chose, PUT et PATCH pour modifier, DELETE pour supprimer, OPTIONS pour demander ce qui est autorisé. Une erreur 405 signifie que l'URL existe, mais pas pour ce verbe. Si l'URL n'existait pas du tout, vous obtiendriez plutôt une erreur 404.

Comme elle concerne la façon dont la requête a été faite et non une page manquante, une erreur 405 est presque toujours à corriger par le développeur du site. Les visiteurs la rencontrent généralement après l'envoi d'un formulaire ou en suivant un lien obsolète.

À quoi ressemble une erreur 405

Étape 1 : lire l'en-tête Allow

Demandez au serveur quelles méthodes il accepte pour cette URL. Envoyez une requête OPTIONS, ou relancez la requête qui échoue en affichant les en-têtes :

# Quelles méthodes cette URL accepte-t-elle ?
curl -i -X OPTIONS https://example.com/api/contact

# Relancez la requête qui échoue et regardez le statut et l'en-tête Allow
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

L'outil En-têtes HTTP de DNS Robot affiche le code de statut et les en-têtes qu'une URL renvoie à une requête GET normale, ce qui aide quand vous vérifiez une page dans le navigateur plutôt qu'une API.

Tous les serveurs ne respectent pas la règle. La page 405 intégrée de nginx, par exemple, est envoyée sans en-tête Allow : sur nginx, vous devrez plutôt vérifier quel bloc location traite l'URL (solution 2).

Si vous êtes un visiteur

• Revenez en arrière et rechargez la page, puis renvoyez le formulaire. Un formulaire chargé depuis une ancienne copie en cache peut envoyer ses données à une adresse qui a changé depuis.

• N'actualisez pas après l'envoi. Actualiser une page issue d'un formulaire peut renvoyer un POST vers une URL qui n'accepte que GET.

• Vérifiez l'adresse pour repérer une faute de frappe, ou ouvrez la page d'accueil du site et naviguez de nouveau.

• Signalez le problème. Si un formulaire du site échoue systématiquement, c'est au propriétaire du site de le corriger : envoyez-lui l'adresse de la page.

Solution 1 : envoyer la bonne méthode à la bonne URL

Dans le code, la cause la plus fréquente est un simple décalage : un formulaire ou un appel fetch() utilise POST alors que le point de terminaison n'accepte que GET, ou la requête part vers l'URL de la page au lieu de l'URL de l'API. Comparez la méthode de votre code avec l'en-tête Allow et la documentation de l'API.

// Le point de terminaison n'accepte que POST : un GET (méthode par défaut de fetch) renvoie 405
const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ana" }),
})
if (res.status === 405) console.log("Allowed:", res.headers.get("allow"))

Solution 2 : nginx renvoie 405 pour un POST vers des fichiers statiques

Le gestionnaire de fichiers statiques de nginx ne sert que GET et HEAD. Un POST vers un fichier .html, ou vers une location qui sert des fichiers au lieu de transmettre la requête à votre application, reçoit 405 Not Allowed. Cela arrive souvent quand l'attribut action d'un formulaire pointe vers une page statique, ou quand un bloc location prévu pour votre application ne correspond pas.

La vraie solution consiste à envoyer le POST à une application (PHP, Node, Python) avec proxy_pass ou fastcgi_pass dans le bon bloc location. Vérifiez quel bloc traite l'URL :

# Les envois de formulaires doivent atteindre l'application, pas le gestionnaire de fichiers statiques
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Testez puis rechargez après chaque modification
# sudo nginx -t && sudo systemctl reload nginx

Solution 3 : IIS bloque PUT et DELETE (WebDAV)

Sur les serveurs Windows qui exécutent IIS, le module WebDAV s'approprie les verbes PUT et DELETE : les API REST (ASP.NET Web API et autres) répondent alors HTTP Error 405.0 pour ces méthodes. Si vous n'utilisez pas WebDAV, retirez-le pour votre site dans web.config :

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

Vérifiez aussi les paramètres de Filtrage des demandes du site dans le Gestionnaire des services Internet (IIS), onglet Verbes HTTP : ils peuvent refuser purement et simplement certaines méthodes (IIS les signale alors en 404.6, pas en 405).

Solution 4 : ajouter la méthode à votre gestionnaire de route

Les frameworks renvoient 405 quand une route existe mais n'a pas de gestionnaire pour la méthode utilisée :

• Next.js (App Router) : un fichier route.ts ne répond qu'aux méthodes qu'il exporte. S'il exporte GET mais pas POST, un POST renvoie 405. Ajoutez export async function POST(request: Request) { … }.

• Flask : les routes n'acceptent que GET par défaut. Utilisez @app.route("/contact", methods=["GET", "POST"]).

• Django : les vues basées sur des classes renvoient 405 pour les méthodes sans gestionnaire correspondant (ajoutez une méthode post()), et le décorateur require_http_methods fait de même.

• Express : par défaut, une méthode non reconnue aboutit à un 404, pas à un 405. Si votre API doit renvoyer 405, ajoutez un gestionnaire fourre-tout qui définit l'en-tête Allow.

Solution 5 : gérer les requêtes de preflight CORS (OPTIONS)

Quand une page web appelle une API sur un autre domaine avec du JSON ou des en-têtes personnalisés, le navigateur envoie d'abord une requête de preflight OPTIONS. Si l'API répond 405 à cette requête OPTIONS, le navigateur signale une erreur CORS et n'envoie jamais la vraie requête, alors même que le vrai point de terminaison aurait fonctionné.

Faites en sorte que l'API réponde à OPTIONS sur ces routes avec un 204 ou un 200 et les bons en-têtes Access-Control-Allow-Methods et Access-Control-Allow-Headers. La plupart des frameworks disposent d'un middleware CORS qui s'en charge pour vous. Par exemple, l'API DNS Lookup de DNS Robot répond au preflight avec un 204 et les en-têtes CORS, afin que les navigateurs puissent l'appeler depuis n'importe quel site.

Erreur 405 ou 400, 403, 404 et 501 : les différences

Guides associés : 400 Bad Request, 403 Forbidden et 401 Unauthorized.