Les erreurs de WordPress ne se produisent pas très souvent, étant donné la stabilité du code de base. De plus, lorsqu’une erreur survient et vous gâche la journée, elle est explicite. L’erreur 414 Request-URI Too Large, par exemple, vous indique exactement quel est le problème. À partir de là, vous pouvez tenter de le résoudre.

Comme pour beaucoup d’autres erreurs de WordPress, il existe des mesures spécifiques que vous pouvez prendre pour résoudre ce problème. En bref, vous devrez ajuster certains réglages de configuration pour autoriser des URL plus longues. Une fois que vous aurez terminé, l’erreur disparaîtra également.

Dans cet article, nous allons vous expliquer comment corriger l’erreur 414 Request-URI Too Large. Il comprendra les outils et les compétences dont vous aurez besoin pour résoudre le problème et énumérera quelques « étapes préalables » avant de passer sous le capot.

Qu’est ce que l’erreur 414 Request-URI Too Large (et pourquoi elle se produit)

L’erreur 414 Request-URL Too Large est un problème de configuration. Il s’agit de l’un des codes d’erreur 400. Ils sont gênants car ils signifient souvent qu’il y a un problème critique entre votre navigateur et le serveur.

Dans ce cas, une erreur 414 signifie que l’URL est trop longue pour que le serveur la traite et qu’il lève une exception. Cela peut être un problème lorsque vous utilisez des codes UTM (Urchin Tracking Module) pour suivre les conversions. Ces liens peuvent être longs en fonction des paramètres que vous définissez, et s’ils atteignent la limite maximale de la configuration de votre site, vous verrez apparaître l’erreur.

Comme pour beaucoup d’erreurs WordPress, il y a beaucoup plus de choses qui se passent sous le capot pour provoquer une 414. En fait, vous pouvez regrouper les causes en trois domaines distincts :

  • La conversion d’une requête POST en requête GET avec des informations de requête trop longues. Il s’agit d’un problème spécifique au développeur qui se produit au niveau du code.
  • Une boucle de redirection. Nous avons parlé des meilleures pratiques en matière de redirections dans un article précédent. Si vous vous retrouvez dans une boucle de redirection, les URL résultantes deviennent trop longues et l’erreur apparaît.
  • Le serveur pourrait être attaqué, et une erreur 414 à ce stade sera le dernier de vos soucis.

Avant de poursuivre, il convient de noter qu’à toutes fins utiles, une URI et une URL sont les mêmes choses. Bien qu’il existe des différences distinctes entre les deux, nous utiliserons le terme « URL » pour simplifier les choses.

Vous avez déjà vu cette erreur apparaître ? 😅 Affrontez-la sans crainte grâce à ce guide 💪Click to Tweet

Ce dont vous avez besoin pour corriger l’erreur 414 Request-URI Too Large

Si vous avez rencontré l’erreur 413 Request Entity Too Large, vous trouverez l’erreur 414 similaire. Bien sûr, les noms montrent leurs similitudes, puisqu’ils se trouvent l’un à côté de l’autre dans les normes officielles et ont des descriptions presque identiques.

Par conséquent, la liste des outils et des compétences que vous utiliserez pour réparer une 413 sera la même pour une 414 :

Si vous êtes client de Kinsta, vous trouverez vos informations d’identification SFTP dans le tableau de bord MyKinsta, ainsi que d’autres fonctionnalités pratiques pour accéder à votre serveur:

Le panneau SFTP dans le tableau de bord MyKinsta.

Le panneau SFTP dans le tableau de bord MyKinsta.

Il convient également de noter que nous nous connecterons ici via SFTP car c’est plus sécurisé (d’où le nom).

Ce qu’il faut faire avant de commencer à résoudre l’erreur 414 Request-URI Too Large

Avant d’ouvrir le capot de votre serveur et de le mettre en service, vous voudrez peut-être effectuer quelques « étapes préalables ». Il se peut qu’il existe une solution de contournement simple qui ne vous oblige pas à modifier vos fichiers de configuration.

De plus, ces vérifications doivent être effectuées à un moment ou à un autre, donc les faire maintenant est une bonne chose à long terme.

Premièrement, une extension WordPress peut générer de longues URL dans le cadre de sa fonctionnalité. Les extensions de sécurité toutes-en-un, peuvent être des candidates de choix ici, surtout si elles offrent beaucoup de fonctionnalités.

Il est difficile de savoir au premier coup d’œil si une extension est en cause, mais cela vaut la peine d’examiner ses réglages spécifiques pour trouver une option dédiée à la restriction de la longueur des URL. Si c’est le cas, l’activation de cette option pourrait résoudre l’erreur 414 en quelques secondes.

Dans des circonstances normales, cependant, il y a quelques autres tâches que vous pouvez effectuer pour vous aider à diagnostiquer l’erreur :

  • Vérifiez si les journaux de votre serveur mentionnent l’erreur ou toute autre entrée d’identification.
  • Les outils de développement de votre navigateur peuvent vous donner des indications sur la cause de l’erreur, notamment votre console.
  • Contactez le propriétaire ou le développeur du site (si ce n’est pas vous) et faites-leur savoir que l’erreur existe. Il se peut qu’ils aient une solution ou qu’ils puissent vous conseiller sur la marche à suivre.

Bien sûr, vous pouvez contacter le site et les développeurs d’extensions si vous avez découvert qu’une extension est en cause. Quoi qu’il en soit, si vous avez épuisé tous vos efforts de vérification de premier niveau, il est temps de partir à l’aventure.

Comment corriger l’erreur 414 Request-URI Too Large (en 3 étapes)

Une fois que vous avez rassemblé vos outils, il vous faut un plan. La solution à l’erreur 414 Request-URI Too Large consiste à modifier un fichier de configuration du serveur. En tant que tel, il y a trois étapes que vous pouvez suivre.

Commençons par entrer dans votre serveur et déterminer quel type de serveur vous avez.

1. Connectez-vous à votre serveur (et déterminez le type de votre serveur)

Vous devez accéder au serveur avant de travailler dessus, et c’est là que vos compétences en matière de SFTP entrent en jeu.

Nous avons déjà expliqué comment accéder à votre site via SFTP. Une fois que vous y êtes, vous devez déterminer le type de serveur dont vous disposez. Il en existe deux types principaux : Apache et Nginx.

Il se peut que vous sachiez déjà quel type de serveur vous utilisez. Si c’est le cas, vous pouvez passer à l’étape suivante.

Si vous avez des difficultés, voici un petit conseil : recherchez un fichier .htaccess. Il se trouve à la racine de votre serveur et si vous pouvez le voir, cela signifie que vous utilisez un serveur Apache. Les serveurs Nginx utilisent un fichier de configuration différent.

Cela dit, il se peut que vous utilisiez un serveur Apache qui n’a pas encore de fichier .htaccess. Dans ce cas, il existe deux autres méthodes que vous pouvez utiliser :

  • Effectuez une recherche de domaine en utilisant le site Whois Domain Tools : Cela peut vous indiquer le type de serveur que vous utilisez, mais ce n’est pas une méthode infaillible.
  • Vérifiez auprès de votre hébergeur le type de serveur que vous utilisez. Bien sûr, votre hébergeur va savoir quel serveur vous utilisez. Les clients de Kinsta utilisent toujours des serveurs Nginx, mais d’autres fournisseurs peuvent utiliser Apache ou un mélange des deux. Il est préférable d’ouvrir un ticket avec votre hébergeur pour vérifier avant de fouiller dans l’administration de votre site.

Lorsque vous avez déterminé le type de serveur que vous utilisez, vous pouvez passer à l’étape suivante et trouver votre fichier de configuration.

2. Trouvez le fichier de configuration du serveur et ouvrez-le dans votre éditeur de texte.

Comme nous l’avons indiqué, les serveurs Apache utilisent un fichier .htaccess pour la configuration de base du serveur, et ce fichier se trouve dans votre répertoire racine. Cependant, ce n’est pas le fichier dont vous avez besoin pour corriger l’erreur 414 Request-URI Too Large.

Dans ce cas, il vous faudra aller plus loin dans vos réglages de configuration avancée. Ceux-ci ne se trouvent pas dans le dossier racine de votre site mais dans celui du serveur.

Vous avez des problèmes de temps d'indisponibilité et de WordPress ? Kinsta est la solution d'hébergement conçue pour vous faire gagner du temps ! Découvrez nos fonctionnalités

Lorsque vous vous connectez à votre site via SFTP, vous arrivez souvent dans un répertoire qui contient tous vos sites (ainsi que d’autres fichiers). Dans de nombreux cas, vous pouvez remonter de quelques niveaux jusqu’à un répertoire racine du serveur :

Naviguer vers la racine du serveur dans Cyberduck.

Naviguer vers la racine du serveur dans Cyberduck.

Cela vous donnera quelques répertoires supplémentaires à parcourir. Parmi eux se trouve le dossier etc :

Le dossier etc dans le répertoire racine d'un serveur.

Le dossier etc dans le répertoire racine d’un serveur.

Le chemin complet du fichier de configuration sera /etc/apache2/apache2.conf.

Le fichier de configuration d'Apache.

Le fichier de configuration d’Apache.

Pour les serveurs Nginx, le processus est similaire. Nous l’avons déjà abordé en partie dans notre article sur le réglage de la taille maximale de téléversement dans WordPress. Le chemin vers le fichier de configuration sera /etc/nginx/nginx.conf.

Une fois que vous avez localisé votre fichier, ouvrez-le dans votre éditeur de texte préféré. À ce stade, vous êtes prêt à l’ajuster.

3. Ajustez le fichier de configuration pour permettre des URL plus longues

Tout comme les serveurs Apache et Nginx ont des fichiers de configuration différents, ils ont également des réglages différents à ajuster. Quel que soit le type de serveur, vous devrez ouvrir le fichier dans un éditeur si vous ne l’avez pas déjà fait. Notre approche préférée est de télécharger le fichier sur votre ordinateur, de travailler dessus puis de le téléverser sur le serveur.

Dans les fichiers de configuration Apache, recherchez le réglage LimitRequestLine, ou ajoutez-le au bas de votre fichier s’il n’y figure pas:

Modification des réglages de configuration du serveur Apache.

Modification des réglages de configuration du serveur Apache.

Pour la valeur, utilisez au moins 128000. Si vous devez aller plus loin, restez sur des multiples de deux (par exemple, la valeur suivante devrait être 256000).

Pour les serveurs Nginx, vous recherchez le réglage large_client_header_buffers. Ici, vous verrez deux valeurs relatives au nombre et à la taille. Par exemple, large_client_header_buffers 4 8K. Le seul chiffre que vous devez modifier ici est la taille – vous pouvez passer de 8K à environ 128K, bien que vous puissiez avoir besoin de l’augmenter davantage (à nouveau par multiples de deux).

Une fois que vous avez terminé, enregistrez vos modifications et téléversez votre fichier de configuration sur votre serveur. À ce stade, vérifiez à nouveau votre site, et l’erreur 414 Request-URI Too Large devrait avoir disparu.

L'erreur 414 Request-URI Too Large peut être ennuyeuse, mais heureusement, elle vous indique exactement quel est le problème. 🤷‍♀️ Apprenez ici à la résoudre 👇Click to Tweet

Résumé

Les erreurs de WordPress ont souvent une approche similaire pour les résoudre. Cependant, vous devrez souvent commencer par diagnostiquer l’erreur. Dans le cas de l’erreur 414 Request-URI Too Large, le problème est clair : les URL transmises au serveur sont trop grandes.

Pour résoudre ce problème, vous devez modifier les réglages de votre serveur Apache ou Nginx. Cela ne prend pas trop de temps, et une fois que vous avez terminé, vous devriez être de nouveau opérationnel. Bien que nous ne puissions pas parler pour d’autres hébergeurs, l’équipe de support de Kinsta est disponible 24/7 pour vous aider à surmonter l’erreur 414 Request-URI Too Large si vous êtes bloqué. En fait, nous sommes là chaque fois que vous avez besoin de notre aide et de nos conseils, afin que vous puissiez exploiter à nouveau votre site.


Économisez du temps et de l’argent et optimisez les performances de votre site avec :

  • Aide instantanée des experts en hébergement WordPress, 24/7.
  • Intégration de Cloudflare Enterprise.
  • Une audience mondiale avec 28 centres de données dans le monde entier.
  • Optimisation avec notre surveillance intégrée de performance d’applications (APM).

Tout cela et bien plus encore, dans un seul plan sans contrat à long terme, avec des migrations assistées et une garantie de remboursement de 30 jours. Pour trouver le plan qui vous convient, Découvrez nos plans ou contactez nous.