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.

Les redirections HTTP 3xx au travail

Les redirections HTTP 3xx au travail

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.

Les redirections HTTP ne sont pas si complexes

Les redirections HTTP ne sont pas si complexes

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 http://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.

La réponse 301 redirige vers la version HTTPS

La réponse 301 redirige vers la version HTTPS

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.

L'en-tête de la réponse de localisation définit l'URL de redirection

L’en-tête de la réponse de localisation définit l’URL de 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.

Les redirections 301 vers le HTTPS ne sont pas sécurisées

Les redirections 301 vers le HTTPS ne sont pas sécurisées

Redirections sécurisées avec 307 Internal Redirect

Maintenant, essayons le même exemple avec Kinsta. La visite de http://kinsta.com conduit à des requêtes de réseau, comme le montre la capture d’écran ci-dessous.

Un exemple de 307 Redirection Interne

Un exemple de 307 Redirection Interne

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.

En-têtes de réponse de la réponse 307 Redirection Interne

En-têtes de réponse de la réponse 307 Redirection Interne

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.

Une meilleure sécurité avec la réponse 307 Redirection Interne

Une meilleure sécurité avec la réponse 307 Internal Redirect

En approfondissant l’en-tête de la réponse à la deuxième requête, nous pourrons mieux comprendre.

Vérification de l'en-tête de réponse HSTS

Vérification de l’en-tête de réponse HSTS

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 :

  1. 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.
  2. 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.
Important

Faire retirer votre domaine de la liste de préchargement HSTS peut être difficile et prendre beaucoup de temps (jusqu’à 12 semaines ou plus). Activez HSTS si et seulement si vous vous engagez pleinement à utiliser le HTTPS sur votre site. Vous pouvez retirer votre site de la liste de préchargement HSTS en envoyant un formulaire sur hstspreload.org.

Ajout de votre site à la liste de préchargement HSTS

Soumission de la liste de préchargement HSTS

Soumission de la liste de préchargement HSTS

Il y a deux façons d’ajouter votre site à la liste de préchargement HSTS.

  1. 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).
  2. 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.

Un exemple de la liste de préchargement HSTS de Mozilla

Un exemple de la liste de préchargement HSTS de Mozilla

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.

HSTS bénéficie d'une large prise en charge sur tous les principaux navigateurs

HSTS bénéficie d’une large prise en charge sur tous les principaux navigateurs

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.

Il existe de nombreux types de codes de statut de redirection HTTP 3xx. Aujourd'hui, il est temps de se plonger dans les codes de statut de redirection temporaire HTTP 307... on se voit de l’autre côté ! 🛤 Cliquez pour Tweet

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.


Si vous avez aimé ce tutoriel, alors vous allez adorer notre support. Tous les plans d’hébergement de Kinsta incluent le support 24/7 de nos développeurs et ingénieurs WordPress expérimentés. Discutez avec la même équipe qui soutient nos clients du Fortune 500. Découvrez nos plans