Le protocole HTTP définit plus de 40 codes de statut de serveur, dont 9 sont explicitement destinés aux redirections d’URL. Chaque code de statut de redirection commence par le chiffre 3 (HTTP 3xx) et possède sa propre méthode de traitement des redirections. Si certains sont similaires, tous s’occupent des redirections de manière différente.
Il est essentiel de comprendre le fonctionnement de chaque code de statut de redirection HTTP pour diagnostiquer ou corriger les erreurs de configuration du site web.
Dans ce guide, nous traiterons en profondeur les codes de statut HTTP 307 Redirection Temporaire (Temporary Redirect) et 307 Redirection Interne (Internal Redirect), y compris leur signification et la façon dont ils diffèrent des autres codes de statut de redirection 3xx.
Commençons !
Comment fonctionnent les redirection HTTP 3xx
Avant de nous plonger dans les réponses 307 Temporary Redirect et 307 Internal Redirect, comprenons comment fonctionne la redirection HTTP.
Les codes de statut HTTP sont des réponses du serveur au navigateur. Chaque code de statut est un nombre à trois chiffres, et le premier chiffre définit le type de réponse dont il s’agit. Les codes de statut HTTP 3xx impliquent une redirection. Ils commandent au navigateur de rediriger vers une nouvelle URL, qui est définie dans l’en-tête Location de la réponse du serveur.
Lorsque votre navigateur rencontre une requête de redirection du serveur, il doit comprendre la nature de cette requête. Les différents codes de statut de redirection HTTP 3xx traitent ces requêtes. Les connaître tous nous aidera à mieux comprendre les codes de redirection 307 Temporary Redirect et 307 Internal Redirect.
Les différentes redirections HTTP 3xx
Il existe plusieurs types de codes de statut de redirection HTTP 3xx. La spécification HTTP originale n’incluait pas les codes 307 Redirection Temporaire et 308 Redirection Permanente, car ces rôles étaient censés être remplis par 301 Déplacé Définitivement (Moved Permanently) et 302 Trouvé (Found).
Cependant, la plupart des clients ont changé la méthode de requête HTTP de POST à GET pour les réponses de redirection 301 et 302, bien que la spécification HTTP ne leur permette pas de le faire. Ce comportement a nécessité l’introduction des codes de statut plus stricts 307 Temporary Redirect et 308 Permanent Redirect dans la mise à jour HTTP/1.1.
La réponse 307 Internal Redirect est une variante du code de statut 307 Temporary Redirect. Elle n’est pas définie par la norme HTTP et n’est qu’une implémentation locale du navigateur. Nous en parlerons plus en détail plus tard.
Alors que les codes de statut de redirection comme 301 et 308 sont mis en cache par défaut, d’autres comme 302 et 307 ne le sont pas. Cependant, vous pouvez rendre cachables toutes les réponses de redirection (ou non) en ajoutant un champ d’en-tête Cache-Control ou Expires response.
Utilisation de 302 vs 303 vs 307 pour les redirections temporaires
Comme le montre le tableau ci-dessus, pour les redirections temporaires, vous avez trois options : 302, 303 ou 307. Cependant, la plupart des clients traitent le code de statut 302 comme une réponse 303 et changent la méthode de requête HTTP pour GET. Ce n’est pas idéal du point de vue de la sécurité.
« RFC 1945 et RFC 2068 précisent que le client n’est pas autorisé à changer de méthode sur la requête redirigée. Cependant, la plupart des implémentations existantes d’agents utilisateurs traitent la 302 comme s’il s’agissait d’une réponse 303, en effectuant un GET sur la valeur du champ Location, quelle que soit la méthode de requête originale. Les codes de statut 303 et 307 ont été ajoutés pour les serveurs qui souhaitent indiquer clairement le type de réaction attendu du client. ”
– HTTP/1.1. Définitions des codes de statut, W3.org
Ainsi, pour les redirections temporaires où vous devez maintenir la méthode de requête HTTP, utilisez la réponse plus stricte 307 Temporary Redirect.
Par exemple, en redirigeant /register-form.html vers signup-form.html, ou de /login.php vers /signin.php.
Pour les cas où vous devez modifier la méthode de requête de redirection vers GET, utilisez plutôt la réponse 303 See Other à la place.
Par exemple, rediriger une requête POST de la page /register.php pour charger une page /success.html via une requête GET.
À moins que votre public cible n’utilise des clients existants, évitez d’utiliser la réponse de redirection 302 Found.
Comprendre les 307 Internal Redirect pour les sites uniquement en HTTPS
Si vous avez un site exclusivement HTTPS (ce que vous devriez faire), lorsque vous essayez de le visiter de manière non sécurisée via le site http://, votre navigateur redirigera automatiquement vers sa version sécurisée https://. Généralement, cela se produit avec une réponse de 301 Moved Permanently du serveur.
Par exemple, si vous visitez https://citibank.com et que vous chargez les Outils de développement dans Chrome et que vous sélectionnez l’onglet Réseau, vous pouvez voir toutes les requêtes effectuées entre le navigateur et le serveur.
La première réponse est 301 Moved Permanently, qui redirige le navigateur vers la version HTTPS du site.
Si l’on creuse davantage les champs Headers de la première requête, on peut voir que l’en-tête de réponse Location définit l’URL sécurisée pour la redirection.
Le problème de cette approche est que des acteurs malveillants peuvent détourner la connexion réseau pour rediriger le navigateur vers une URL personnalisée. Les attaques de type Man-in-the-Middle (MITM) sont assez courantes. Une série télévisée populaire l’a même usurpée dans un de ses épisodes.
De plus, une partie malveillante peut lancer une attaque MITM sans modifier l’URL affichée dans la barre d’adresse du navigateur. Par exemple, l’utilisateur peut recevoir une page d’hameçonnage (phishing) qui ressemble exactement au site d’origine.
Et comme tout se ressemble, y compris l’URL dans la barre d’adresse, la plupart des utilisateurs seront heureux de taper leurs identifiants. Vous pouvez imaginer pourquoi cela peut être mauvais.
Redirections sécurisées avec 307 Internal Redirect
Maintenant, essayons le même exemple avec Kinsta. La visite de https://kinsta.com conduit à des requêtes de réseau, comme le montre la capture d’écran ci-dessous.
La première requête du site est comme l’exemple précédent, mais cette fois-ci, elle conduit à une réponse 307 Internal Redirect. En cliquant dessus, vous aurez plus de détails sur cette réponse.
Note : Si vous essayez de visiter le site directement avec https://, vous ne verrez pas cet en-tête car le navigateur n’a pas besoin d’effectuer de redirection.
Notez l’en-tête de réponse Non-Authoritative-Reason : HSTS. Il s’agit de l’en-tête de réponse Strict Transport Security (HSTS) de HTTP, également connu sous le nom de Strict-Transport-Security.
Qu’est-ce que le HSTS (Strict Transport Security) ?
L’IETF a ratifié le HTTP Strict Transport Security (HSTS) en 2012 pour forcer les navigateurs à utiliser des connexions sécurisées lorsqu’un site fonctionne strictement en HTTPS.
C’est un peu comme si Chrome ou Firefox disaient : « Je n’essaierai même pas de demander ce site ou l’une de ses ressources par le biais du protocole HTTP non sécurisé. Je vais plutôt le changer en HTTPS et réessayer ».
Vous pouvez suivre le guide de Kinsta sur la façon d’activer le HSTS pour qu’il soit opérationnel sur votre site WordPress.
En approfondissant l’en-tête de la réponse à la deuxième requête, nous pourrons mieux comprendre.
Ici, vous pouvez voir l’en-tête de réponse strict-transport-security : max age=315536000.
L’attribut max-age de l’en-tête de réponse strict-transport-security définit la durée pendant laquelle le navigateur doit suivre ce modèle. Dans l’exemple ci-dessus, cette valeur est fixée à 3153600 secondes (ou 1 an).
Une fois qu’un site renvoie cet en-tête de réponse, le navigateur n’essaie même pas de faire une requête HTTP ordinaire. Il effectue plutôt une 307 Internal Redirect vers HTTPS et réessaye.
Chaque fois que ce processus se répète, les en-têtes de réponse sont réinitialisés. Ainsi, le navigateur ne pourra pas faire de requête non sécurisée pendant une période indéterminée.
Si vous hébergez votre site chez Kinsta, vous pouvez créer un ticket de support pour que l’en-tête HSTS soit ajouté à votre site WordPress. Comme l’ajout de l’en-tête HSTS permet de bénéficier d’avantages en termes de performances, il est recommandé d’activer HSTS pour votre site.
Qu’est-ce qu’une liste de préchargement HSTS ?
Il y a un problème de sécurité flagrant même avec le HSTS. La toute première requête HTTP que vous envoyez avec le navigateur n’est pas sécurisée, répétant ainsi le problème que nous avons observé précédemment avec Citibank.
En outre, l’en-tête de réponse HSTS ne peut être envoyé que par HTTPS, de sorte que la requête initiale non sécurisée ne peut même pas être renvoyée.
Pour résoudre ce problème, HSTS prend en charge un attribut de préchargement dans son en-tête de réponse. L’idée est d’avoir une liste de sites qui appliquent HSTS à précharger dans le navigateur lui-même, en contournant complètement ce problème de sécurité.
L’ajout de votre site à la liste de préchargement HSTS du navigateur lui permettra de savoir que votre site applique une politique stricte en matière de HSTS, même s’il visite votre site pour la première fois. Le navigateur utilisera alors la réponse 307 Internal Redirect pour rediriger votre site vers son schéma sécurisé https:// avant de demander autre chose.
Vous devez noter que contrairement à la réponse 307 Temporary Redirect, la réponse 307 Internal Redirect est un « faux en-tête » défini par le navigateur lui-même. Elle ne provient pas du serveur, de l’hébergeur web (par exemple Kinsta), ou du CMS (par exemple WordPress).
L’ajout d’un site à une liste de préchargement HSTS présente de nombreux avantages :
- Le serveur web ne voit jamais les requêtes HTTP non sécurisées. Cela réduit la charge du serveur et rend le site plus sûr.
- Le navigateur se charge de la redirection du HTTP vers le HTTPS, ce qui rend le site plus rapide et plus sûr.
Exigences relatives à la liste de préchargement HSTS
Si vous souhaitez ajouter votre site à la liste de préchargement HSTS d’un navigateur, celui-ci doit cocher les conditions suivantes :
- Avoir un certificat SSL/TLS valide installé pour votre domaine.
- Faire respecter un HTTPS strict en redirigeant tout le trafic HTTP vers le HTTPS.
- Tous les sous-domaines doivent être desservis par HTTPS, en particulier le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine.
- Votre domaine de base doit inclure un en-tête HSTS avec les attributs suivants :
- L’attribut max-age doit être défini pendant au moins 31536000 secondes (1 an).
- Les directives includeSubdomains et preload doivent être spécifiées.
- Si vous effectuez une redirection supplémentaire, celle-ci doit inclure l’en-tête HSTS, et non la page vers laquelle elle redirige.
Ajout de votre site à la liste de préchargement HSTS
Il y a deux façons d’ajouter votre site à la liste de préchargement HSTS.
- En soumettant votre site à un répertoire de liste de préchargement HSTS. Par exemple, la liste principale de hstspreload.org est gérée par le projet open source Chromium et est utilisée par la plupart des grands navigateurs (Firefox, Chrome, Safari, IE 11 et Edge).
- En ajoutant le champ d’en-tête suivant à votre site :
Strict-Transport-Sécurité : max-age=63072000 ; includeSub-Domains ; preload
Avec la seconde méthode, la toute première visite de votre site par le navigateur ne sera pas totalement sécurisée. En revanche, les visites suivantes seront entièrement sécurisées.
Vous pouvez utiliser un outil en ligne gratuit comme Security Headers pour vérifier si votre site applique ou non HSTS. Si la prise en charge du HSTS par les navigateurs vous inquiète, sachez que HSTS est pris en charge par la quasi-totalité des navigateurs utilisés aujourd’hui.
Redirections HTTP 307 et SEO
Étant donné qu’une réponse 307 Temporary Redirect montre que la ressource a été temporairement déplacée vers une nouvelle URL, les moteurs de recherche ne mettent pas à jour leur index pour inclure cette nouvelle URL. Le « jus de lien » de l’URL d’origine n’est pas transmis à la nouvelle URL.
Cela contraste avec les redirections 301 Moved Permanently, où les moteurs de recherche mettent à jour leur index pour inclure la nouvelle URL et transmettent le « jus de lien » de l’URL d’origine à la nouvelle URL.
Avec une réponse 307 Internal Redirect, tout se passe au niveau du navigateur. Elle ne devrait donc pas avoir d’effet direct sur le référencement de votre site. Toutefois, l’ajout de votre site à une liste de préchargement HSTS le rend plus rapide et plus sûr, ce qui peut l’aider à se classer plus haut dans les résultats de recherche.
Faites attention à ne pas rediriger par inadvertance les utilisateurs et les robots dans une boucle de redirection infinie, ce qui provoquerait l’erreur « trop de redirections ».
Résumé
La redirection d’URL vous permet d’attribuer plusieurs adresses URL à une page web. La meilleure façon de gérer les redirections d’URL est au niveau du serveur avec des réponses de code de statut de redirection HTTP 3xx. Si votre site est en panne pour des raisons de maintenance ou indisponible pour d’autres raisons, vous pouvez le rediriger temporairement vers une autre URL avec une réponse 307 Temporary Redirect.
Cela étant dit, toute redirection ajoute un décalage au temps de chargement de votre page. Par conséquent, utilisez les redirections judicieusement en gardant toujours à l’esprit l’expérience de l’utilisateur final.
