HTTP 307 : comprendre le HTTP 307 et tout ce qu’il faut savoir sur la redirection temporaire

Pre

Le code de statut HTTP 307, aussi nommé HTTP 307 Temporary Redirect en anglais, est l’un des mécanismes clés pour gérer les redirections sur le Web sans perdre les propriétés essentielles de la requête. Dans cet article, nous explorerons en profondeur ce qu’est le HTTP 307, pourquoi il est utilisé, comment il se distingue des autres codes de redirection, et comment le mettre en œuvre correctement côté serveur et côté client. Que vous soyez développeur backend, administrateur système, référence SEO ou simplement curieux des subtilités des codes de statut HTTP, vous trouverez ici une ressource complète et pratique sur le HTTP 307.

HTTP 307 : définition et contexte

Qu’est-ce que HTTP 307 ?

HTTP 307 est un code de statut de redirection qui indique que la ressource demandée réside temporairement sous une URI différente. Contrairement à certaines redirections passées, le HTTP 307 précise que la méthode HTTP d’origine et le corps de la requête doivent être conservés lors de la requête suivante vers la nouvelle localisation. Autrement dit, si vous avez envoyé une POST, une PUT ou une autre méthode, la requête redirigée doit reprendre exactement la même méthode et le même corps, mais vers l’URL cible fournie dans l’en-tête Location.

Historique et sémantique

Dans les premières versions du protocole HTTP, le comportement exact des redirections semblait varier selon les navigateurs et les clients. Le code 307 a été introduit pour clarifier une situation ambiguë autour du code 302, qui pouvait conduire certains clients à changer la méthode de la requête lors de la redirection. Avec le HTTP 307, on stipule explicitement la préservation de la méthode et du corps. Cette précision est cruciale pour les API REST et les flux d’authentification où la méthode et les données de la requête doivent rester intactes après la redirection.

HTTP 307 vs les autres codes de redirection

HTTP 301 et HTTP 302

Le HTTP 301 est une redirection permanente : l’URL d’origine est définitivement remplacée par la nouvelle URL, et les moteurs de recherche mettront à jour leurs index en conséquence. En revanche, le HTTP 302 est une redirection temporaire; historiquement, certains clients ne savaient pas s’ils devaient conserver la méthode ou non, ce qui a conduit à des ambiguïtés. Le HTTP 307 règle cette ambiguïté en réaffirmant que la méthode et le corps ne doivent pas être modifiés.

HTTP 303 et HTTP 307 : quelles différences ?

Le HTTP 303 See Other conduit souvent les clients à effectuer une requête GET sur la nouvelle URL, même si la requête initiale utilisait une autre méthode (par exemple POST). Le 307, lui, conserve la méthode d’origine et le corps, ce qui peut être indispensable pour des flux d’API. En pratique, le choix entre 303 et 307 dépend du comportement souhaité côté client et de la nature de votre flux.

Quand opter pour HTTP 307 ?

Utilisez HTTP 307 lorsque la redirection est temporaire et que vous souhaitez préserver les propriétés de la requête initiale. Cela est particulièrement utile lors de rechargements d’authentification, de migrations légères d’URL pendant une maintenance, ou encore lors de redirections dynamiques qui ne changent pas le comportement du client. Si la redirection est destinée à devenir définitive, préférez HTTP 301 afin d’aider les moteurs de recherche à mettre à jour les index et à transférer l’équité des liens.

Fonctionnement technique du HTTP 307

Comportement attendu par le client

Lorsqu’un client reçoit une réponse HTTP 307 avec un en-tête Location indiquant une nouvelle URL, il doit effectuer une nouvelle requête en utilisant exactement la même méthode que la requête initiale et en transmettant le même corps, vers la URL fournie. Le header Location est essentiel, il transmet l’adresse cible vers laquelle rediriger. Les en-têtes supplémentaires, comme Authorization, peuvent être réutilisés si nécessaire, sous réserve des règles du protocole et des politiques serveur.

Impact sur la sécurité et les en-têtes

Le HTTP 307, en préservant la méthode et le corps, peut impliquer la réutilisation d’assertions d’authentification ou de tokens dans la requête redirigée. Il est donc crucial de s’assurer que la redirection ne transmet pas d’informations sensibles à une destination non fiable. Les administrateurs doivent vérifier que l’en-tête Location ne pointe pas vers des domaines potentiellement malveillants et qu’un contrôle de domaine est en place lorsque cela est nécessaire.

Caching et validité

La redirection 307 n’est pas, par défaut, garantie d’être mise en cache. Le comportement exact dépend des en-têtes Cache-Control et Expires présents dans la réponse et de la configuration du cache côté client ou serveur. Si une redirection temporaire peut être mise en cache, cela se fait uniquement avec des directives explicites. En pratique, le serveur et les développeurs doivent configurer le caching avec prudence pour éviter des comportements inattendus lors des redirections temporaires.

Cas concrets et scénarios d’utilisation

Redirection temporaire dans une API

Dans une API REST, une ressource peut être temporairement déplacée pendant une opération de maintenance ou lors d’un rechargement interne. Le HTTP 307 permet de diriger les clients vers une URL alternative sans changer la méthode POST ou PUT, ce qui est crucial pour des flux d’échanges de données sécurisés et cohérents. Par exemple, lors d’un déploiement, une API peut rediriger temporairement les clients vers une version miroir sans perturber les intégrations existantes.

Migration d’URL lors d’un rebranding

Lors d’un rebranding ou d’une réorganisation des structures d’URL, il peut être utile d’employer HTTP 307 pour éviter une perte immédiate de trafic lors d’un test A/B ou d’une transition progressive. Une redirection temporaire permet d’évaluer l’impact et de préparer une migration plus pérenne avec un code 301 lorsque les URL finales seront stabilisées.

A/B testing et maintenance

En contexte d’A/B testing, HTTP 307 peut diriger une partie du trafic vers une version expérimentale sans modifier les attentes des clients ni les méthodes employées. Cette approche est particulièrement adaptée lorsque les tests nécessitent de conserver les mêmes verbes HTTP et le même flux de données. Toutefois, pour les moteurs de recherche, l’usage d’un 307 dans ce cadre doit être soigneusement documenté et aligné avec la stratégie SEO globale.

Mises en œuvre côté serveur : exemples concrets

Nginx

Pour générer une redirection HTTP 307 en interne sur Nginx, vous pouvez utiliser la directive « return ». Exemple :

location /ancienne-url {
    return 307 /nouvelle-url;
}

Cette approche est simple et rapide et permet une redirection temporaire tout en conservant la méthode et le corps de la requête initiale.

Apache

Avec Apache, vous pouvez utiliser la directive Redirect ou des règles mod_rewrite. Exemple avec Redirect 307 :

Redirect 307 /ancienne-url /nouvelle-url

Alternativement, avec mod_rewrite :

RewriteEngine On
RewriteRule ^ancienne-url(.*)$ /nouvelle-url$1 [R=307,L]

Les deux approches permettent d’obtenir une redirection temporaire tout en préservant la méthode d’origine.

Express.js (Node.js)

Dans Express, la méthode res.redirect peut prendre le statut en premier argument. Exemple :

app.post('/ancienne-url', function(req, res) {
  res.redirect(307, '/nouvelle-url');
});

Cela garantit que la requête POST initiale est réécrite vers la nouvelle URL sans changer la méthode.

PHP

En PHP, utilisez header avec le code 307 :

header("Location: /nouvelle-url", true, 307);
exit;

Cette approche est simple et largement compatible avec les environnements PHP classiques.

Java et Spring Boot

Dans les frameworks Java, vous pouvez définir le statut explicitement lors d’un redirection. Exemple avec Spring :

return ResponseEntity.status(HttpStatus.TEMPORARY_REDIRECT)
                     .location(URI.create("/nouvelle-url"))
                     .build();

Cette méthode garantit une redirection temporaire et le respect de la méthode d’origine.

Impact sur le SEO et les performances

Comment les moteurs interprètent HTTP 307

Les moteurs de recherche interprètent HTTP 307 comme une redirection temporaire. Leur recommandation générale est de considérer que la ressource d’origine reste la même du point de vue de l’indexation, et que l’objectif est une expérience utilisateur fluide pendant une période limitée. Si l’objectif est une migration permanente, il convient d’utiliser HTTP 301 pour favoriser la consolidation des signaux de classement vers la nouvelle URL.

Bonnes pratiques SEO autour du HTTP 307

Erreurs fréquentes et comment les éviter

Outils et méthodes pour tester HTTP 307

Curl et tests manuels

Pour tester rapidement une redirection 307, vous pouvez utiliser curl et demander les en-têtes sans suivre la redirection :

curl -I -X GET https://example.com/ancienne-url

Pour faire suivre la redirection et observer le comportement :

curl -I -L -X POST https://example.com/ancienne-url

HTTPie et autres outils

HTTPie offre une syntaxe conviviale pour tester les codes de statut et suivre les redirections. Exemple :

http -f POST https://example.com/ancienne-url

Navigateurs et devtools

Les DevTools des navigateurs (F12) permettent de visualiser les requêtes et les réponses, y compris le code HTTP 307 et l’en-tête Location. Utilisez l’onglet Network pour inspecter les redirections et vérifier que la méthode est conservée dans les requêtes suivantes.

Bonnes pratiques et conseils pour les développeurs

Quand privilégier HTTP 301 plutôt que HTTP 307

Si l’objectif est une migration définitive des URL, privilégiez HTTP 301 afin d’indiquer clairement aux moteurs de recherche et aux navigateurs que l’emplacement est permanent. Le 301 transmettra davantage de valeur de lien et facilitera la consolidation des signaux d’autorité des pages vers la nouvelle adresse.

Gestion des authentifications et des sessions

Dans les flux nécessitant une authentification, soyez conscient que les redirections HTTP 307 peuvent réutiliser des jetons d’accès ou des cookies. Assurez-vous que les destinations de redirection demeurent sécurisées et sous contrôle et que les politiques CORS et SameSite des cookies ne compromettent pas la sécurité.

Compatibilité et comportements cross-platform

La plupart des clients modernes respectent le HTTP 307 et conservent la méthode et le corps lors de la redirection. Toutefois, dans des environnements plus anciens ou des outils propriétaires, vérifiez toujours le comportement spécifique et ajustez la configuration en conséquence.

Diversité des usages : un regard global

Cas d’usage typiques dans des organisations

Cas d’usage moins fréquents mais pertinents

FAQ rapide sur HTTP 307

HTTP 307 et POST : que se passe-t-il ?

Avec HTTP 307, si vous envoyez une requête POST et que le serveur répond par une redirection 307, le client doit effectuer une nouvelle requête vers l’URL de destination en utilisant la même méthode POST et le même corps. Cela évite les surprises quant à la manière dont les données du formulaire ou les charges utiles sont traitées à la ressource cible.

Le 307 peut-il être mis en cache ?

Le comportement de mise en cache pour HTTP 307 dépend des en-têtes de contrôle fournis par le serveur. En l’absence de directives claires, les redirections temporaires ne doivent pas être considérées comme des cibles de caching, afin d’éviter des incohérences. Si vous souhaitez autoriser le caching, ajoutez les directives appropriées comme Cache-Control et ETag, et documentez clairement la durée de validité.

Différence entre HTTP 307 et HTTP 302

Si vous ne spécifiez pas le code de redirection explicitement, certains systèmes peuvent renvoyer 302 par défaut. La différence clé réside dans la préservation de la méthode et du corps : HTTP 307 conserve la méthode et le corps, alors que HTTP 302 ne garantit pas cela et peut amener le client à effectuer une requête GET à la destination. Pour les API et les flux nécessitant de garder une POST, HTTP 307 est le choix approprié.

Conclusion : optimiser vos redirections avec le HTTP 307

Le HTTP 307 est un outil puissant pour gérer des redirections temporaires tout en préservant l’intégrité des requêtes côté client. En l’utilisant à bon escient, vous pouvez orchestrer des transitions techniques sans perturber les flux d’API, les intégrations et l’expérience utilisateur. Souvenez-vous que le choix entre HTTP 307 et d’autres codes de redirection doit être guidé par l’objectif, qu’il s’agisse d’une opération temporaire ou d’une migration permanente. Avec des configurations serveur claires, des tests rigoureux et une approche SEO réfléchie, le HTTP 307 devient un élément fiable et efficace de votre arsenal HTTP.

Pour résumer, vous entendrez souvent parler du HTTP 307 dans les documents techniques et les guides de développement, et parfois vous verrez aussi l’expression http code 307 employée dans des contextes plus informels. Quoi qu’il advienne, l’usage correct du HTTP 307 vous permettra d’assurer une redirection temporaire robuste, tout en respectant les attentes des clients et des moteurs de recherche. En maîtrisant ses subtilités, vous optimisez les flux de vos applications et garantissez une expérience utilisateur cohérente même lors des périodes de maintenance ou de réorganisation des URLs.