L'erreur "trop de redirections" signifie que le site Web continue d'être redirigé entre différentes adresses d'une manière qui ne se terminera jamais. Cela est souvent le résultat de redirections concurrentes, l'une essayant de forcer HTTPS (SSL) et l'autre redirigeant vers HTTP (non-SSL), ou entre les formes www et non-www de l'URL.
Si vous utilisez un CMS comme Wordpress, Magento, etc., qui utilise une base_url ou la configuration du type d'URL dans le site, vous pouvez vous retrouver avec la configuration dans le code ou la base de données en conflit avec une redirection dans un fichier .htaccess. Ces redirections conflictuelles feront des allers-retours et ne se termineront jamais.
Votre navigateur vous protège de cela en n'autorisant qu'un certain nombre de redirections (souvent une dizaine) avant d'abandonner et de signaler le message d'erreur "trop de redirections". Cela s'affiche différemment entre Chrome, Firefox et les autres navigateurs.
Firefox
La page n'est pas redirigée correctement. Une erreur s'est produite lors d'une connexion au
Chrome
Cette page ne fonctionne pas
Même l'utilitaire de test curl abandonne après 50 redirections par défaut.
Courbure : Maximum (X) redirections suivies
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedPremière étape :cache et cookies
Comme indiqué dans les erreurs de navigateur ci-dessus, ces redirections en boucle peuvent également être causées par des cookies dans le navigateur qui mettent en cache les anciennes redirections. La première étape du test consisterait à vider votre cache et vos cookies dans votre navigateur. Si vous avez déjà effacé le cache et les cookies du navigateur, il est temps de passer à un dépannage plus avancé.
Utilisation des outils de développement pour les boucles de redirection
La prochaine étape du dépannage de ces types de boucles de redirection consiste à utiliser les outils de développement dans Firefox ou Chrome. Ces outils sont généralement ouverts en appuyant sur la touche F12. Assurez-vous de sélectionner le Réseau onglet dans l'un d'entre eux, puis rechargez la page avec laquelle vous rencontrez un problème.
Après avoir rechargé la page, vous devriez voir la série de redirections répertoriées pour vous dans la nouvelle fenêtre. En regardant les redirections, vous pouvez voir si elles redirigent entre plusieurs choses différentes ou redirigent vers la même chose. Dans les deux cas, vous pouvez voir les étapes qui ont conduit à l'erreur, au lieu de simplement l'erreur de navigateur de l'utilisateur final.
Outils de développement dans Firefox
Utilisation de cURL pour les boucles de redirection
Dans le cadre de la rédaction de cet article, nous avons créé un script Bash assez simple qui peut être utilisé sur n'importe quel système de type Unix avec le curl commande. L'utilisation de curl est agréable, car elle ne met pas les choses en cache de la même manière que les navigateurs, elle peut donc parfois vous donner une perspective différente lors du dépannage.
Copiez ce qui suit dans votre éditeur de texte préféré et enregistrez-le sous redirects.sh .
#!/bin/bash
echo
for domain in $@; do
echo --------------------
echo $domain
echo --------------------
curl -sILk $domain | egrep 'HTTP|Loc' | sed 's/Loc/ -> Loc/g'
echo
doneMarquez ensuite le redirects.sh fichier en tant qu'exécutable.
chmod +x redirects.shVous pouvez exécuter notre script, comme dans les exemples ci-dessous, en ajoutant votre domaine après le nom du script. Il peut même vérifier plusieurs domaines et il vérifiera les redirections de chaque URL, à son tour, en plaçant un en-tête entre les domaines distincts testés.
Exemple de sortie
./redirects.sh liquidweb.com
--------------------
liquidweb.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://liquidweb.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.liquidweb.com/
HTTP/1.1 200 OKExemple de redirection infinie de HTTP vers HTTPS
./redirects.sh http://www.example.com
--------------------
http://www.example.com
--------------------
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
....
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: http://www.example.com/
HTTP/1.1 301 Moved Permanently
-> Location: https://www.example.com/Note complémentaire sur les types de redirection
En regardant la boucle ci-dessus, vous pouvez voir que le code de réponse HTTP est 301. Les redirections 301 sont des redirections "permanentes", ce qui signifie que quelque chose a été déplacé de manière permanente et que vous ou votre navigateur devez le rechercher dans le nouvel emplacement maintenant et à l'avenir. Les redirections 302 sont des redirections "temporaires", ce qui signifie que quelque chose a bougé pour le moment, mais peut ne pas toujours être au nouvel emplacement.
Les redirections 301 sont le plus souvent écrites sous forme d'entrées de redirection ou de réécriture dans un fichier .htaccess. Cependant, les redirections 302, que ce soit par conception ou par convention, sont souvent générées dans le code d'un site Web. Donc, une bonne règle de base est que les 301 sont dans les fichiers .htaccess et que les 302 sont dans le code du site. Ce n'est peut-être pas toujours vrai, mais c'est une bonne chose à garder à l'esprit.
Redirections dans le fichier .htaccess
Le fichier .htaccess est un fichier de configuration utilisé pour modifier le comportement du serveur Apache par répertoire sur un site Web/serveur. Il s'agit d'un fichier de configuration au niveau de l'utilisateur, et seules certaines configurations Apache peuvent être modifiées ici, bien que les redirections soient couramment utilisées.
Vous pouvez avoir plusieurs fichiers .htaccess qui cascadent sur une série de répertoires. Si vous avez un .htaccess dans un répertoire parent et un autre dans un sous-répertoire, ils affecteront tous les deux le sous-répertoire. Dans ces cas, il est important de se rappeler où vous avez et où vous n'avez pas de fichiers .htaccess, pour éviter les conflits entre les fichiers .htaccess à différents niveaux.
Vous trouverez ci-dessous une série d'exemples de redirection qui vous aideront à identifier les redirections dans votre fichier .htaccess. Ce ne sont pas les seules façons d'effectuer ce type de redirections, mais celles-ci devraient vous montrer à quoi ressemblent les redirections les plus courantes afin que vous puissiez les reconnaître si elles se trouvent dans un fichier .htaccess avec lequel vous travaillez.
Forcer HTTPS
Le code .htaccess ci-dessous vérifie d'abord si la demande est arrivée au serveur via HTTP ou HTTPS. Si la requête n'a pas utilisé HTTPS, la configuration indiquera au navigateur de rediriger vers la version HTTPS du même site Web et de la même URL que celle demandée auparavant.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Forcer HTTPS :lorsque derrière un équilibreur de charge ou un proxy (CloudFlare/Incapsula/Sucuri/etc.)
Parfois, vous pouvez utiliser un proxy, comme un équilibreur de charge ou un pare-feu Web, comme CloudFlare, Incapsula ou Sucuri. Ceux-ci peuvent être configurés pour utiliser SSL sur le front-end, mais pas pour utiliser SSL sur le back-end. Pour que cela fonctionne correctement, vous devez vérifier non seulement HTTPS dans la demande, mais également si le proxy a transmis la demande HTTPS d'origine au serveur en utilisant uniquement HTTP. Cette règle suivante vérifie si la requête a été transmise depuis HTTPS et, si c'est le cas, n'essaie pas de rediriger une fois de plus.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Forcer non-www
Cette redirection vérifie uniquement si le nom du site Web a été demandé avec www au début du nom de domaine. Si le www est inclus, il réécrit la requête et indique au navigateur de rediriger vers la version non-www du nom de domaine.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Forcer www
Cette dernière redirection vérifie si le nom du site n'a pas été demandé avec www au début du nom de domaine. Si le www n'est pas inclus, il réécrit la requête et indique au navigateur de rediriger vers la version www du domaine.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
Le CMS WordPress utilise un fichier .htaccess pour réécrire les URL dans index.php fichier, mais il définit l'URL du site Web comme une valeur dans la base de données. Si vous ne connaissez pas déjà le nom de la base de données utilisée sur le site, vous pouvez le rechercher dans la configuration principale de WordPress (wp-config.php ).
Vous pouvez également ouvrir le fichier dans un éditeur de texte et rechercher ces valeurs, mais à partir d'une connexion SSH, vous pouvez utiliser le programme grep . Cela vous donne plus que le nom de la base de données, mais le nom de la base de données est le plus important pour ce que nous devons faire ensuite.
grep DB wp-config.php
define('DB_NAME', 'wordpress_database');
define('DB_USER', 'wordpress_username');
define('DB_PASSWORD', 'Password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');Le tableau wp_options
Une fois que vous connaissez le nom de la base de données, vous pouvez alors consulter le tableau des options de la base de données Wordpress pour voir à quoi l'URL est définie dans la base de données. La table d'options peut avoir n'importe quel préfixe au début du nom de la table, mais il s'agit souvent de "wp_" par défaut, le nom complet de la table d'options est donc généralement wp_options . Les deux lignes importantes sont home et siteurl lignes du tableau des options. Vous pouvez les trouver en utilisant phpMyAdmin , ou un autre utilitaire de gestion de base de données, mais à partir de la ligne de commande, vous pouvez également simplement exécuter le mysql suivant commande.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsVérification de l'URL configurée
À partir de la ligne de commande, vous pouvez vérifier quelles sont les valeurs actuelles de la home et siteurl lignes du tableau des options. La commande devrait vous envoyer et sortir comme dans l'exemple ci-dessous. L'important est qu'ils correspondent dans la plupart des cas et qu'ils correspondent à ce que vous attendez. S'ils ne correspondent pas à vos attentes, vous devrez les mettre à jour en conséquence.
mysql -e 'select * from wp_options where option_name rlike "home|siteurl"' wordpress_database
+-----------+-------------+----------------------------------+----------+
| option_id | option_name | option_value | autoload |
+-----------+-------------+----------------------------------+----------+
| 36 | home | http://www.example.com | yes |
| 1 | siteurl | http://www.example.com | yes |
+-----------+-------------+----------------------------------+----------+Mettre à jour l'URL configurée
La commande suivante mettra à jour les deux lignes de wp_options table pour une base de données donnée vers une nouvelle URL. Cette commande convient à la plupart des situations où vous devez mettre à jour ou corriger l'URL configurée pour un site Wordpress. Mise à jour des base_urls configuré dans un Wordpress Multisite dépasse le cadre de cet article, mais impliquerait la mise à jour de plusieurs wp_option tapez des tableaux.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
Le nom de la base de données Magento est configuré dans l'un des fichiers suivants, local.xml ou env.php . Vous pouvez également configurer un préfixe pour les noms de table de la base de données Magento, mais il n'est généralement pas défini. Ainsi, le nom attendu pour la table de configuration principale de la base de données est simplement core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpLe tableau core_config_data
Il existe de nombreuses URL potentielles qui peuvent être configurées, mais elles ont toutes "base_url " dans le cadre de la ligne dans la base de données. Les URL principales configurées seront les URL sécurisées et non sécurisées, mais vous pouvez également configurer des URL pour les images, les fichiers de thème ou même configurer une URL distincte pour la zone d'administration du site. Vous pouvez à nouveau les trouver à l'aide d'un utilitaire de gestion de base de données, mais à partir de la ligne de commande, vous pouvez exécuter quelque chose comme ce qui suit.
mysql -e 'select * from core_config_data where path rlike "base_url"' magento_database
+-----------+---------+----------+-----------------------+----------------------------+
| config_id | scope | scope_id | path | value |
+-----------+---------+----------+-----------------------+----------------------------+
| 3 | default | 0 | web/unsecure/base_url | http://www.example.com |
| 4 | default | 0 | web/secure/base_url | http://www.example.com |
+-----------+---------+----------+-----------------------+----------------------------+Pour mettre à jour les base_urls dans la base de données Magento, vous exécuteriez quelque chose comme la commande ci-dessous. La mise à jour des base_urls d'un multisite Magento dépasse également le cadre de cet article, mais impliquerait en outre de référencer le scope_id spécifique valeur pour le site Web ou le magasin donné configuré dans la base de données Magento.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseTout résumer
Avec les URL configurées dans la base de données, comme indiqué ci-dessus, il convient de noter que ces CMS fournissent également leurs propres méthodes de redirection dans le code du site. Si, par exemple, vous avez une redirection .htaccess qui redirige vers une URL qui ne correspond pas à ce qui se trouve dans la base de données, vous pouvez vous retrouver avec la boucle de redirection infinie comme décrit précédemment. Cependant, vous savez maintenant à quoi ressemblent certaines redirections .htaccess courantes et où trouver les URL configurées dans certaines bases de données logicielles CMS. Vous êtes également bien équipé pour tester, enquêter et confirmer si ces choses fonctionnent de concert ou les unes contre les autres, et quelques étapes pour les résoudre.