De foutmelding "te veel omleidingen" betekent dat de website steeds wordt omgeleid tussen verschillende adressen op een manier die nooit zal worden voltooid. Vaak is dit het resultaat van concurrerende omleidingen, waarbij de ene HTTPS (SSL) probeert te forceren en de andere die terugleidt naar HTTP (niet-SSL), of tussen www- en niet-www-vormen van de URL.
Als u een CMS gebruikt zoals Wordpress, Magento, enz., gebruikt dat een base_url of URL-type configuratie binnen de site, kan de configuratie in de code of database in conflict komen met een omleiding in een .htaccess-bestand. Deze tegenstrijdige omleidingen zullen heen en weer gaan en nooit voltooien.
Uw browser beschermt u hiertegen door slechts een bepaald aantal omleidingen toe te staan (vaak tien of zo) voordat deze het opgeeft en de foutmelding "te veel omleidingen" meldt. Dit wordt anders weergegeven tussen Chrome, Firefox en andere browsers.
Firefox
De pagina wordt niet correct omgeleid. Er is een fout opgetreden tijdens een verbinding met
Chroom
Deze pagina werkt niet
Zelfs het testprogramma curl geeft standaard op na 50 omleidingen.
Krul: Maximum (X) gevolgde omleidingen
curl -svILk https://www.example.com
....
* Maximum (50) redirects followedDe eerste stap:cache en cookies
Zoals blijkt uit de browserfouten hierboven, kunnen deze doorverwijzingen in een lus ook worden veroorzaakt door cookies in de browser die oude omleidingen in de cache plaatsen. De eerste stap bij het testen is om uw cachegeheugen en cookies in uw browser te wissen. Als je het cachegeheugen en de cookies in de browser al hebt gewist, is het tijd om verder te gaan met wat geavanceerdere probleemoplossing.
Ontwikkelaarstools gebruiken voor omleidingslussen
De volgende stap bij het oplossen van problemen met dit soort omleidingslussen is het gebruik van de Developer Tools in Firefox of Chrome. Deze tools worden gewoonlijk geopend door op de F12-toets te drukken. Zorg ervoor dat u het Netwerk . selecteert tab in een van deze en laad vervolgens de pagina waarmee u een probleem ondervindt opnieuw.
Na het herladen van de pagina, zou u de reeks omleidingen voor u moeten zien in het nieuwe venster. Als je naar de omleidingen kijkt, kun je zien of ze omleiden tussen een paar verschillende dingen of omleiden naar hetzelfde. Hoe dan ook, u kunt de stappen zien die tot de fout hebben geleid, in plaats van alleen de browserfout van de eindgebruiker.
Ontwikkelaarstools in Firefox
CURL gebruiken voor omleidingslussen
Als onderdeel van het schrijven van dit artikel hebben we een vrij eenvoudig Bash-script samengesteld dat kan worden gebruikt op elk Unix-achtig systeem met de krul opdracht. Het gebruik van curl is leuk, omdat het dingen niet op dezelfde manier in de cache opslaat als browsers, dus het kan je soms een ander perspectief geven bij het oplossen van problemen.
Kopieer het volgende naar de teksteditor van uw voorkeur en sla het op als 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
doneMarkeer vervolgens de redirects.sh bestand als uitvoerbaar.
chmod +x redirects.shU kunt ons script uitvoeren, zoals in de onderstaande voorbeelden, door uw domein achter de scriptnaam toe te voegen. Het kan zelfs meerdere domeinen controleren en het zal de omleidingen van elke URL controleren, en op zijn beurt een header tussen afzonderlijke geteste domeinen plaatsen.
Voorbeelduitvoer
./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 OKVoorbeeld van een oneindige omleiding van HTTP naar 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/Een kanttekening over omleidingstypen
Kijkend naar de krul uitvoer hierboven kunt u zien dat de HTTP-responscode 301 is. 301-omleidingen zijn "permanente" omleidingen, wat betekent dat iets permanent is verplaatst, en u of uw browser moet het nu en in de toekomst opzoeken op de nieuwe locatie. 302-omleidingen zijn "tijdelijke" omleidingen, wat betekent dat er iets is verplaatst voor nu, maar niet altijd op de nieuwe locatie.
301-omleidingen worden vaker wel dan niet weggeschreven als omleidings- of herschrijvingsitems in een .htaccess-bestand. 302-omleidingen, ofwel door ontwerp of conventie, worden echter vaak gegenereerd binnen de code van een website. Dus een goede vuistregel is dat 301's in .htaccess-bestanden zitten en 302's in sitecode. Dit is misschien niet altijd waar, maar het is goed om in gedachten te houden.
Omleidingen in het .htaccess-bestand
Het .htaccess-bestand is een configuratiebestand dat wordt gebruikt om het gedrag van de Apache-server per map op een website/server te wijzigen. Dit is een configuratiebestand op gebruikersniveau en slechts enkele Apache-configuraties kunnen hier worden bewerkt, hoewel omleidingen algemeen worden gebruikt.
U kunt meerdere .htaccess-bestanden hebben die over een reeks mappen lopen. Als je een .htaccess in een bovenliggende map hebt, en een andere in een submap, hebben ze allebei invloed op de submap. In deze gevallen is het belangrijk om te onthouden waar u wel en niet over .htaccess-bestanden beschikt, om conflicten tussen .htaccess-bestanden op verschillende niveaus te voorkomen.
Hieronder vindt u een reeks voorbeelden van omleidingen die helpen bij het identificeren van omleidingen in uw .htaccess-bestand. Dit zijn niet de enige manieren om dit soort omleidingen uit te voeren, maar deze zouden u moeten laten zien hoe de meest voorkomende omleidingen eruit zien, zodat u ze kunt herkennen als ze zich in een .htaccess-bestand bevinden waarmee u werkt.
HTTPS forceren
Onderstaande .htaccess-code controleert eerst of het verzoek via HTTP of HTTPS op de server is binnengekomen. Als het verzoek geen HTTPS gebruikte, zal de configuratie de browser vertellen om door te verwijzen naar de HTTPS-versie van dezelfde website en URL die eerder was aangevraagd.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]HTTPS forceren:achter een load balancer of proxy (CloudFlare/Incapsula/Sucuri/etc.)
Soms gebruikt u mogelijk een proxy, zoals een load balancer of een webfirewall, zoals CloudFlare, Incapsula of Sucuri. Deze kunnen worden geconfigureerd om SSL aan de voorkant te gebruiken, maar niet om SSL aan de achterkant te gebruiken. Om dit correct te laten werken, moet u niet alleen controleren op HTTPS in het verzoek, maar ook of de proxy het oorspronkelijke HTTPS-verzoek met alleen HTTP aan de server heeft doorgegeven. Deze volgende regel controleert of het verzoek is doorgestuurd vanaf HTTPS, en zo ja, probeer dan niet nog een keer om te leiden.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Niet-www forceren
Deze omleiding controleert alleen of de websitenaam is aangevraagd met www aan het begin van de domeinnaam. Als de www is opgenomen, herschrijft het het verzoek en vertelt het de browser om door te verwijzen naar de niet-www-versie van de domeinnaam.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]Www forceren
Deze laatste omleiding controleert of de websitenaam niet is opgevraagd met www aan het begin van de domeinnaam. Als de www niet is opgenomen, herschrijft het het verzoek en vertelt het de browser om door te verwijzen naar de www-versie van het domein.
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]WordPress
Het WordPress CMS gebruikt een .htaccess-bestand voor het herschrijven van URL's naar de index.php bestand, maar het definieert de URL van de website als een waarde in de database. Als u de naam van de database die op de site wordt gebruikt nog niet weet, kunt u deze opzoeken in de hoofdconfiguratie voor WordPress (wp-config.php ).
Je kunt het bestand ook in een teksteditor openen en naar deze waarden zoeken, maar vanuit een SSH-verbinding kun je het programma grep gebruiken . Dit geeft u meer dan alleen de databasenaam, maar de databasenaam is het belangrijkste voor wat we nu moeten doen.
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', '');De wp_options-tabel
Als je eenmaal de naam van de database weet, kun je in de optietabel van de Wordpress-database kijken waar de URL op is ingesteld in de database. De optietabel kan elk voorvoegsel aan het begin van de tabelnaam hebben, maar het is vaak "wp_" standaard, dus de volledige naam van de optietabel is meestal wp_options . De twee regels die belangrijk zijn, zijn de home en siteurl regels in de optietabel. U kunt deze vinden met phpMyAdmin , of een ander hulpprogramma voor databasebeheer, maar vanaf de opdrachtregel kunt u ook gewoon het volgende mysql uitvoeren commando.
mysql -e 'show tables' wordpress_database | grep options
prefix_optionsDe geconfigureerde URL controleren
Vanaf de opdrachtregel kunt u controleren wat de huidige waarden van de home en siteurl regels in de optietabel. De opdracht zou u moeten verzenden en uitvoeren zoals in het onderstaande voorbeeld. Het belangrijkste is dat deze onder de meeste omstandigheden op elkaar aansluiten en dat ze zijn wat je verwacht. Als ze niet zijn wat je verwacht, wil je ze dienovereenkomstig bijwerken.
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 |
+-----------+-------------+----------------------------------+----------+De geconfigureerde URL bijwerken
Met de volgende opdracht worden de twee rijen van de wp_options . bijgewerkt tabel voor een bepaalde database naar een nieuwe URL. Deze opdracht is geschikt voor de meeste situaties waarin u de URL die voor een Wordpress-site is geconfigureerd, moet bijwerken of corrigeren. De base_urls bijwerken geconfigureerd in een Wordpress Multisite valt buiten het bestek van dit artikel, maar vereist het bijwerken van meerdere wp_option typ tabellen.
mysql -e 'update wp_options set option_value="https://www.example.com" where option_name rlike "home|siteurl"' wordpress_databaseMagento
De naam van de Magento-database wordt geconfigureerd in een van de volgende bestanden, local.xml of env.php . U kunt ook een prefix configureren voor de tabelnamen van de Magento-database, maar deze is meestal niet ingesteld. Dus de verwachte naam voor de hoofdconfiguratietabel van de database is gewoon core_config_data .
# Version 1.x
app/etc/local.xml
# Version 2.x
app/etc/env.phpDe core_config_data-tabel
Er zijn veel potentiële URL's die kunnen worden geconfigureerd, maar ze hebben allemaal "base_url " als onderdeel van de regel in de database. De primaire geconfigureerde URL's zijn de veilige en onveilige URL's, maar u kunt ook URL's instellen voor afbeeldingen, themabestanden of zelfs een aparte URL instellen voor het beheergedeelte van de site. U kunt deze opnieuw vinden met een hulpprogramma voor databasebeheer, maar vanaf de opdrachtregel kunt u zoiets als het volgende uitvoeren.
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 |
+-----------+---------+----------+-----------------------+----------------------------+De base_urls bijwerken in de Magento-database zou je zoiets als het onderstaande commando uitvoeren. Het updaten van de base_urls van een Magento Multisite valt ook buiten het bestek van dit artikel, maar zou extra verwijzen naar de specifieke scope_id waarde voor de opgegeven website of winkel geconfigureerd in de Magento-database.
mysql -e 'update core_config_data set value="https://www.example.com" where path rlike "web/.*/base_url"' magento_databaseAlles afronden
Met URL's geconfigureerd in de database, zoals hierboven weergegeven, is het vermeldenswaard dat deze CMS'en ook hun eigen omleidingsmethoden bieden binnen de sitecode. Als u bijvoorbeeld een .htaccess-omleiding hebt die omleidt naar een URL die niet overeenkomt met wat er in de database staat, kunt u eindigen met de oneindige omleidingslus zoals eerder beschreven. U weet nu echter hoe sommige algemene .htaccess-omleidingen eruit zien en waar u de geconfigureerde URL's kunt vinden in sommige CMS-softwaredatabases. Je bent ook goed uitgerust om te testen, te onderzoeken en te bevestigen of deze dingen samenwerken of tegen elkaar werken, en enkele stappen om ze op te lossen.