Het HTTP protocol definieert meer dan 40 server-statuscodes. Hiervan zijn 9 expliciet bedoel voor URL redirects. Elke redirectstatuscode begint met het cijfer 3 (HTTP 3xx) en heeft zijn eigen methode om de redirect af te handelen. Hoewel sommige erg op elkaar lijken, gaan ze allemaal anders om met redirects.
Wanneer je fouten wat betreft websiteconfiguratie wil oplossen of diagnosticeren, dan is het cruciaal om te begrijpen hoe elke HTTP redirectstatuscode werkt.
In deze gids behandelen we de statuscodes HTTP 307 Temporary Redirect en 307 Internal Redirect uitgebreid, inclusief waarom ze zo belangrijk zijn en hoe ze verschillen van andere 3xx redirectstatuscodes.
Aan de slag!
Hoe werken HTTP 3xx redirects
Voordat we ingaan op de statuscodes 307 Temporary Redirect en 307 Internal Redirect, moeten we eerst begrijpen hoe HTTP redirects werken.
HTTP statuscodes zijn antwoorden van de server naar de browser. Elke statuscode is een driecijferig nummer waarvan het eerste cijfer aangeeft wat voor soort reactie het is. HTTP 3xx statuscodes impliceren een redirect. Ze geven de browser de opdracht om naar een nieuwe URL te gaan. Deze URL is gedefinieerd in de Location header van het antwoord van de server.
Wanneer je browser op een redirectverzoek stuit van de server, dan moet deze de aard van dit verzoek begrijpen. De verschillende HTTP 3xx redirectstatuscodes behandelen deze verzoeken. Als je ze allemaal kent, dan snap je de 307 Temporary Redirect en 307 Internal Redirect ook beter.
De verschillende HTTP 3xx redirects
Er zijn verschillende soorten HTTP 3xx redirectstatuscodes. De oorspronkelijke HTTP specificatie bevatte geen 307 Temporary Redirect en 308 Permanent Redirect. Het was de bedoeling dat deze rollen werden vervuld door 301 Moved Permanently en 302 Found.
De meeste clients wijzigden echter de HTTP aanvraagmethode van POST naar GET voor de redirectresponses 301 en 302, ondanks dat de clients dit niet mochten doen van de HTTP specificatie. Dit gedrag zorgde voor de introductie van de strengere statuscodes 307 Temporary Redirect en 308 Permanent Redirect in de HTTP/1.1 update.
De 307 Internal Redirect respons is een variant van de 307 Temporary Redirect statuscode. Deze is niet gedefinieerd door de door HTTP opgelegde standaard, maar is een lokale browserimplementatie. Later bespreken we dit in meer detail.
Redirectstatuscodes als 301 en 308 worden standaard in de cache opgeslagen, maar dit geldt bijvoorbeeld niet voor 302 en 307. Je kan echter alle redirectresponses cachebaar maken (of juist niet) door het toevoegen van de responsheader Cache-Control of Expires.
302 vs 303 vs 307 gebruiken voor tijdelijke redirects
Zoals je kan zien in bovenstaande grafiek, heb je voor tijdelijke redirects drie mogelijkheden: 302, 303 of 307. De meeste clients behandelen de 302 statuscode als een 303 respons en veranderen de HTTP aanvraagmethode in GET. Vanuit een veiligheidsoogpunt is dit verre van ideaal.
“RFC 1945 en RFC 2068 specificeren dat de client de methode van het redirectverzoek niet mag wijzigen. De meeste user-agent implementaties behandelen de 302 echter als een 303 respons, waarbij een GET wordt uitgevoerd als veldwaarde in Location, ongeacht de oorspronkelijke aanvraagmethode. De statuscodes 303 en 307 zijn toegevoegd voor servers die ondubbelzinnig duidelijk willen maken welk soort reactie wordt verwacht van de client.”
– HTTP/1.1. Status Code Definitions, W3.org
Gebruik daarom voor tijdelijke redirects, waarbij je de HTTP aanvraagmethode moet handhaven, de striktere 307 Temporary Redirect respons.
Bijvoorbeeld het omleiden van /registratie-formulier.html naar inschrijf-formulier.html of van /login.php naar /inloggen.php.
Voor gevallen waarin je de redirectverzoek-methode wil wijzigen naar GET, gebruik je in plaats daarvan de respons 303 See Other.
Denk bijvoorbeeld aan een POST redirectverzoek omleiden van de /register.php pagina naar de pagina /succes.html via een GET verzoek.
Tenzij je doelgroep vaak gebruikmaakt van oudere clients: vermijd het gebruik van de redirectrespons 302 Found.
Uitleg over 307 Internal Redirect voor sites met alleen HTTPS
Als je een HTTPS-only site hebt (wat je zou moeten hebben), en je probeert deze te bezoeken via het onveilige http://, dan zal je browser je automatisch omleiden naar de beveiligde https:// versie. Dit gebeurt normaal gesproken met een 301 Moved Permanent redirectrespons van de server.
Als je bijvoorbeeld http://citibank.com bezoekt, DevTools laadt in Chrome en het Network tabblad selecteert, dan kan je alle verzoeken zien die zijn gedaan tussen de browser en server.
De eerste respons is 301 Moved Permanently, die de browser redirect naar de HTTPS versie van de site.
Als we beter kijken naar de Headers velden van het eerste verzoek, dan zien we dat de Location responsheader aangeeft wat het de beveiligde URL van de redirect is.
Het probleem van deze methode is dat kwaadwillenden de netwerkverbinding kunnen kapen om de browser te redirecten naar een URL van hun keuze. Deze zogenaamde Man-in-the-Middle (MITM) aanvallen komen helaas vrij vaak voor. Een populaire tv-serie stak er zelfs de draak mee in een van hun afleveringen.
Ook kunnen kwaadwillenden een MITM aanval starten zonder de URL in de adresbalk van de browser te wijzigen. De gebruiker kan bijvoorbeeld een phishing-pagina te zien krijgen die er precies zo uitziet als de oorspronkelijke site.
En aangezien alles er hetzelfde uitziet, inclusief de URL in de adresbalk, vullen de meeste gebruikers zonder blikken of blozen hun inloggegevens in. Je kan je voorstellen dat dit alles enorm problematisch is.
Veilige redirects met 307 Internal Redirect
Laten we nu eens Kinsta als voorbeeld nemen. Een bezoek aan https://kinsta.com zorgt voor netwerkverzoeken zoals weergegeven in de onderstaande schermafbeelding.
Het eerste verzoek van de site is vergelijkbaar met die uit het eerste voorbeeld. Er is echter een groot (maar subtiel) verschil: dit keer zorgt het voor een 307 Internal Redirect respons. Als je erop klikt, zie je meer details over deze respons.
Opmerking: Als je de site rechtstreeks bezoekt met https://, dan krijg je deze headertekst niet, omdat de browser geen redirect hoeft uit te voeren.
Let ook op de responsheader Non-Authoritative-Reason: HSTS. Dit is HTTP’s Strict Transport Security (HSTS), ook wel bekend als de responsheader Strict-Transport-Security.
Wat is HSTS (Strict Transport Security)?
In 2012 ratificeerde het IETF de HTTP STrict Transport Security (HSTS) om browsers te dwingen om beveiligde verbindingen te gebruiken wanneer een site uitsluitend op HTTPS draait.
Dit kan je interpreteren als dat Chrome/Firefox zeggen: “Ik probeer niet eens om deze site of een van de bijbehorende te laden via het onveilige HTTP protocol. In plaats daarvan verander ik het in HTTPS en probeer ik het opnieuw.”
Je kan Kinsta’s handleiding volgen over hoe je HSTS kan inschakelen om het ook op WordPress site werkend te krijgen.
Als we beter kijken naar de responsheader van het tweede verzoek, dan zien we al waarom 307 Internal Redirect veel veiliger is.
Hier kan je de responsheader strict-transport-security: max age=31536000 zien.
Het attribuut max-age van de responsheader strict-transport-security bepaalt hoe lang de browser dit patroon moet volgen. In het bovenstaande voorbeeld is deze waarde ingesteld op 31.536.000 seconden (oftewel 1 jaar).
Zodra de site deze responsheader retourneert, dan weet de browser dat deze niet eens hoeft te proberen om een HTTP verzoek te doen. In plaats daarvan zal het een 307 Internal Redirect naar HTTPS uitvoeren en het opnieuw proberen.
Elke keer dat dit proces zich herhaalt, worden de responsheaders gereset. Daarom is het (voor onbepaalde tijd) niet mogelijk dat de browser een onveilig verzoek indient.
Als je je site bij Kinsta host, dan kan je een supportticket aanmaken om de HSTS header aan je WordPress site toe te voegen. Omdat het toevoegen van de HSTS voor betere performance zorgt, raden we aan om HSTS op je site in te schakelen.
Wat is een HSTS Preload lijst?
Er is met HSTS echter wel een duidelijk beveiligingsprobleem. Het allereerste HTTP verzoek dat je met je browser stuurt is onveilig. Dit zorgt voor hetzelfde probleem als dat we eerder bij Citibank zagen.
Bovendien kan de HSTS responsheader alleen via HTTPS worden verstuurd. Het initiële onveilige verzoek kan dus niet eens worden geretourneerd.
Om dit probleem aan te pakken, ondersteunt HSTS een preload-attribuut in zijn responsheader. Het idee hierachter is om een lijst met sites te hebben waarvan wordt afgedwongen dat HSTS vooraf wordt geladen door de browser zelf. Hiermee wordt dit beveiligingsprobleem dus omzeild.
Door je site toe te voegen aan de HTTS Preload lijst, laat je het weten dat je site een strikt HSTS beleid hanteert, zelfs als de site voor het eerst wordt bezocht. De browser gebruikt vervolgens de 307 Internal Redirect respons om je site naar het veilige https:// schema te redirecten, voordat deze iets anders aanvraagt.
Houd er rekening mee dat, in tegenstelling tot 307 Temporary Redirect, de 307 Internal Redirect respons een “neppe header” is die door de browser zelf is ingesteld. Het komt dus niet van de server, de webhost (bijvoorbeeld Kinsta) of het CMS (bijvoorbeeld WordPress).
Het toevoegen van een HSTS Preload lijst heeft veel voordelen:
- De webserver krijgt nooit meer te maken met onveilige HTTP verzoeken. Dit verminder belasting op de server en maakt de site veiliger.
- De browser zelf zorgt voor de redirect van HTTP naar HTTPS, wat de site sneller en veiliger maakt.
Vereisten voor de HSTS Preload lijst
Als je je site aan de HSTS Preload lijst van een browser wil toevoegen, dan moet deze voldoen aan de volgende voorwaarden:
- Zorgen dat er een geldig SSL/TLS certificaat is geïnstalleerd voor het domein.
- Het afdwingen van strikte HTTPS door al het HTTP verkeer te redirecten naar HTTPS.
- Alle subdomeinen moeten worden aangeboden via HTTPS, met name het www subdomein als er een DNS record bestaat voor dat subdomein.
- Je basisdomein moet een HSTS header bevatten met de volgende kenmerken:
- Het max-age attribuut moet worden ingesteld op minimaal 31.536.000 seconden (1 jaar).
- De directives includeSubdomains en preload moeten worden gespecificeerd.
- Als je een extra redirect levert, moet deze de HSTS header bevatten en niet de pagina waarnaar deze redirect.
Je site toevoegen aan de HSTS Preload lijst
Er zijn twee manieren om je site toe te voegen aan de HSTS Preload lijst.
- Door je site in te dienen bij een HSTS Preload lijst-directory. De hoofdlijst hstspreload.org wordt bijvoorbeeld bijgehouden door het Chromium opensource project en wordt gebruikt door de meeste grote browsers (Firefox, Chrome, Safari, IE 11 en Edge).
- Door het volgende headerveld aan je site toe te voegen:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Met de tweede methode is het allereerste bezoek van de browser aan je site niet volledig veilig. De bezoeken erna zijn echter wel volledig veilig.
Je kan een gratis online tool als Security Headers gebruiken om te kijken of je site HSTS afdwingt of niet. Als je zorgen maakt over of wel genoeg browsers HSTS ondersteunen, dan is het goed om te weten dat HSTS wordt ondersteund door vrijwel alle browsers die vandaag de dag worden gebruikt.
HTTP 307 redirects en SEO
Omdat een 307 Temporary Redirect respons aangeeft dat de bron TIJDELIJK naar een nieuwe URL is verplaatst, werken zoekmachines hun index niet bij met deze nieuwe URL. De “link juice” van de oorspronkelijke URL wordt dus niet doorgegeven aan de nieuwe URL.
Dit in tegenstelling tot de 301 Moved Permanently redirects, waarbij zoekmachines hun index wel bijwerken met de nieuwe URL en de “link juice” van de oorspronkelijke URL doorgeven aan de nieuwe URL.
Met een 307 Internal Redirect respons gebeurt alles op browserniveau. Het zou daarom geen effect moeten hebben op de SEO van je site. Als je je site echter toevoegt aan een HSTS Preload lijst, dan wordt deze veiliger en sneller geladen. Beide dragen bij aan een hogere ranking in de zoekresultaten.
Pas op dat je gebruikers en bots niet per ongeluk redirect naar een oneindige redirectloop, wat de fout “too many redirects” veroorzaakt.
Samenvatting
URL redirects zorgen dat je meer dan één URL adres kan toewijzen aan een webpagina. De beste manier om URL redirects af te handelen is op serverniveau met HTTP 3xx redirectstatuscode responses. Als je site tijdelijk niet beschikbaar is vanwege onderhoud of om andere redenen niet bereikbaar is, dan kan je tijdelijk een omleiding instellen met een 307 Temporary Redirect respons.
Dat gezegd hebbende, elke redirect zorgt voor vertraging en een lagere paginalaadtijd. Maak daarom op een verstandige manier gebruik van redirects en houd de gebruikerservaring altijd in het achterhoofd.
