Erreur 405 sur un lien : comparez HEAD et GET

Ne déclarez pas le lien cassé à partir du seul nombre

Votre navigateur ouvre une page, mais une vérification renvoie 405. Cet écart demande une investigation, pas la suppression immédiate du lien. Selon la réponse reçue, le code signifie que la méthode demandée n’est pas prise en charge pour cette ressource. Il ne confirme ni l’existence du contenu, ni son caractère public, ni sa disponibilité pour chaque visiteur. Conservez l’adresse exacte et le nom de l’outil utilisé.

Sur Stack Overflow, une personne rapporte des erreurs 405 après avoir remplacé GET par HEAD dans une vérification. Une autre question sur Reddit décrit de faux positifs avec un programme de contrôle des liens. Ces témoignages ne prouvent pas la cause de votre problème. Cette démarche compare les requêtes puis le contenu avant de modifier le lien, le vérificateur ou la configuration du site.

Ce qui distingue HEAD de GET

GET demande une représentation de la ressource ; HEAD demande les métadonnées correspondant à GET, sans le corps de cette réponse. MDN documente cette distinction. Demander seulement les en-têtes peut réduire les transferts, mais ne permet pas de lire la page ni de confirmer la présence du document attendu. Une application ou un intermédiaire peut aussi gérer les méthodes différemment. Notez donc la méthode rejetée.

Selon RFC 9110, une réponse 405 doit inclure Allow avec les méthodes actuellement admises pour la ressource. Consultez cet en-tête si l’outil l’affiche. S’il manque, notez cette absence ; n’inventez pas sa valeur et ne supposez pas qu’autoriser chaque méthode résoudrait le problème. La réponse donnée en exemple est fictive. Allow ne remplace pas la vérification de la méthode nécessaire.

HTTP/1.1 405 Method Not Allowed
Allow: GET

Comparez des requêtes interprétables

Si vous administrez le site et maîtrisez le terminal, comparez HEAD et GET sur la même adresse publique de consultation. Les commandes montrent les en-têtes ; la seconde abandonne le corps après réception et peut donc télécharger des données. Remplacez example.invalid par votre page autorisée. Ce domaine est fictif, pas un service disponible à tester. Évitez les actions d’achat, de suppression ou de déconnexion.

Gardez la même URL et les mêmes conditions maîtrisables. Notez l’heure, la méthode, le statut et une éventuelle redirection. Les commandes ne suivent pas les redirections : examinez leur destination avant d’y renouveler la demande. N’ajoutez pas d’identifiants et ne copiez pas de cookies privés dans un outil public. Un navigateur connecté et une requête anonyme depuis une autre machine ne constituent pas une comparaison équivalente.

curl --head --max-time 20 "https://example.invalid/guide"
curl --silent --show-error --max-time 20 --dump-header - --output /dev/null "https://example.invalid/guide"

Interprétez sans conclure trop vite

Si HEAD reçoit 405 et GET reçoit 200 dans des conditions comparables, vous pouvez constater deux réponses différentes. Il faut encore ouvrir la page et vérifier son contenu. Si GET reçoit également 405, le problème n’est pas démontré comme spécifique à HEAD. Si GET reçoit 404, la première requête HEAD ne prouvait pas l’existence de la page. Distinguez observations et hypothèses.

Ne transformez pas un formulaire POST en GET pour masquer l’erreur : cela peut modifier son fonctionnement et exposer des données dans l’adresse. Ne désactivez pas les protections et n’autorisez pas des méthodes d’écriture par commodité. Pour votre site, transmettez les résultats à la personne chargée des routes et règles serveur. Pour un autre site, demandez un lien public approprié ou signalez le problème sans données sensibles.

Ajoutez une vérification WikiURL

Collez l’adresse publique complète dans le vérificateur d’URL WikiURL et conservez le statut HTTP ainsi que l’adresse finale détectée. C’est une observation supplémentaire depuis le serveur du service. Elle ne reproduit pas nécessairement votre navigateur, votre session ou les commandes précédentes. L’interface ne permet pas de sélectionner manuellement HEAD ou GET ; ne lui attribuez pas une comparaison qu’elle n’affiche pas.

Ouvrez ensuite la destination réelle dans le navigateur et confirmez que la page convient au public prévu. En cas de désaccord, gardez les deux résultats et leurs conditions. Un statut 200 ne certifie ni le contenu ni la sécurité ; un 405 isolé ne suffit pas à retirer un lien. Réunissez des éléments permettant de corriger le composant précis, sans transformer une étiquette en diagnostic complet.

Conservez une décision vérifiable avant diffusion

Préparez une fiche avec URL, date, outil, méthode connue ou non observée, statut, destination finale et contenu vérifié. Indiquez en attente lorsqu’un essai manque. Conservez les en-têtes utiles sans jetons, cookies ni données personnelles. Pour une autre personne chargée de l’examen, fournissez ce résumé et le comportement attendu plutôt qu’une conclusion encore insuffisamment étayée.

Après une correction concrète, refaites une vérification proportionnée et confirmez le contenu avant de raccourcir l’adresse ou créer un QR avec WikiURL. Ces formats facilitent le partage sans modifier les méthodes admises ni réparer la ressource. Gardez le lien de référence avec le fichier publié. Vous distinguerez ainsi différence entre clients, méthode rejetée et mauvaise destination sans supprimer une adresse valide sur une seule réponse.