Configurer une redirection 307 (Apache / Nginx / PHP)
Snippets testés pour mettre en place une 307 côté serveur ou application, sans casser les parcours sensibles.
Objectif : copier / coller une configuration fiable, puis vérifier en 2 minutes (curl + DevTools).
Pré-requis non négociables
- Une 307 doit rester temporaire (définir une date de fin / un ticket).
- Éviter les chaînes (une seule redirection idéalement).
- Tester sur un POST réel si vous redirigez une route sensible.
Où configurer la 307 (serveur vs PHP)
Le meilleur endroit est presque toujours le serveur (Apache/Nginx). PHP est utile si vous ne contrôlez pas la conf serveur.
- Vous avez accès à Apache (.htaccess/vhost) → configurez côté serveur (plus simple, plus performant).
- Vous avez accès à Nginx (server/location) → utilisez
return 307pour les règles simples. - Vous n’avez pas la main serveur (hébergement mutualisé / contraintes CMS) → redirigez en PHP.
Heuristique “prod”
Si vous devez rediriger une route critique (paiement/login/API), privilégiez une règle serveur + un test sur la méthode réelle.
En PHP, un header envoyé trop tard, une sortie bufferisée ou une erreur de session peut rendre le comportement instable.
Configurer une redirection 307 avec Apache
Deux approches courantes : Redirect 307 (simple) et RewriteRule (flexible).
Apache : exemple simple avec Redirect 307 (.htaccess)
À utiliser pour une redirection 1→1, sans logique complexe.
## Redirection 307 simple (temporaire)
## Source : /ancienne-route
## Cible : /nouvelle-route
Redirect 307 /ancienne-route /nouvelle-routeNote
Redirect vient de mod_alias. Pour des règles conditionnelles/regex, passez à RewriteRule.
Apache : avec RewriteRule (mod_rewrite)
À utiliser si vous devez matcher un pattern, gérer des paramètres, ou éviter d’impacter certaines routes.
## Active mod_rewrite
RewriteEngine On
## Exemple 1 : redirection 307 d’une route exacte
RewriteRule ^ancienne-route/?$ /nouvelle-route [R=307,L]
## Exemple 2 : rediriger tout un répertoire en conservant le reste du chemin
## /old/* → /new/*
RewriteRule ^old/(.*)$ /new/$1 [R=307,L]Apache : configuration propre en VirtualHost (recommandé en prod)
Si vous contrôlez le vhost, c’est souvent plus propre que le .htaccess (moins de surcharge, règles centralisées).
<VirtualHost *:443>
ServerName www.exemple.com
## Option 1 : Redirect simple (mod_alias)
Redirect 307 /ancienne-route /nouvelle-route
## Option 2 : mod_rewrite (regex / conditions)
RewriteEngine On
RewriteRule ^old/(.*)$ /new/$1 [R=307,L]
</VirtualHost>Erreurs fréquentes (Apache)
- Oublier
[R=307,L]: la règle match mais ne renvoie pas le bon statut. - Écrire une règle trop large (regex) et créer une boucle involontaire.
- Mettre la redirection après d’autres règles qui réécrivent déjà l’URL.
Configurer une redirection 307 avec Nginx
Pour la majorité des cas : préférez return 307. rewrite est utile surtout pour des regex avancées.
Nginx : return 307 (recommandé)
Cas simple et lisible. Parfait pour une redirection 1→1 ou une route précise.
server {
listen 443 ssl;
server_name www.exemple.com;
## Redirection 307 d’une route exacte
location = /ancienne-route {
return 307 /nouvelle-route;
}
}Nginx : rediriger un répertoire (en conservant le reste du chemin)
server {
listen 443 ssl;
server_name www.exemple.com;
## /old/* → /new/*
location ^~ /old/ {
return 307 /new$request_uri;
}
}Important
Si vous utilisez /new$request_uri, vous obtenez /new/old/.... Pour un mapping propre old→new,
préférez un rewrite avec capture.
Nginx : rewrite (cas avancés / regex)
À utiliser quand vous devez capturer une partie de l’URL et la réinjecter proprement dans la cible.
server {
listen 443 ssl;
server_name www.exemple.com;
## /old/* → /new/*
location / {
rewrite ^/old/(.*)$ /new/$1 redirect;
}
}Pièges Nginx (à éviter)
rewrite ... redirect;renvoie généralement une redirection “standard” (souvent 302), pas forcément 307.- Une règle trop large dans
location /peut rediriger des assets (JS/CSS) et casser l’UI. - Tester en “browser only” peut masquer des comportements de cache : validez aussi au curl.
Recommandation
Si votre cas Nginx implique une regex, utilisez une config explicite (capture) et vérifiez le statut retourné (307)
au curl. Sur des routes sensibles, ne laissez pas une ambiguïté “rewrite redirect”.
Configurer une redirection 307 en PHP
À utiliser quand vous n’avez pas accès à la conf serveur, ou quand la redirection dépend d’une logique applicative.
PHP : exemple minimal avec header()
Envoyez le statut 307 + l’en-tête Location, puis stoppez l’exécution avec exit;.
<?php
// Redirection 307 (temporaire) vers une nouvelle URL
// IMPORTANT : aucune sortie (echo/HTML) avant ces headers.
header('Location: /nouvelle-route', true, 307);
exit;PHP : gérer une redirection conditionnelle (ex. maintenance sur une route)
<?php
$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
// Exemple : rediriger temporairement /checkout vers /checkout-maintenance
if ($path === '/checkout') {
header('Location: /checkout-maintenance', true, 307);
exit;
}WordPress / frameworks : principe (sans vous enfermer dans un plugin)
L’idée est la même : renvoyer une réponse 307 + Location. Exemple WordPress :
<?php
// Exemple : dans un hook adapté (template_redirect)
// wp_redirect($url, $status);
wp_redirect(home_url('/nouvelle-route'), 307);
exit;Routes POST sensibles : points de vigilance
- Évitez toute redirection si les headers sont déjà envoyés (buffer/echo) → comportement aléatoire.
- Sur un POST contenant des données sensibles, contrôlez strictement la destination (pas d’open redirect).
- Testez le parcours complet (session, cookies, CSRF) : une redirection peut casser un middleware.
Bonnes pratiques (chaînes, durée, cache, prod)
- Définissez une date de fin (ou un ticket) : une 307 “oubliée” devient un problème de gouvernance.
- Une seule redirection : évitez les chaînes (latence + complexité).
- Routes critiques : test sur la méthode réelle (POST/PUT), pas uniquement sur GET.
- Cache : si besoin, forcer
Cache-Control: no-storepour éviter des comportements agressifs (CDN / navigateur). - Préprod : validez d’abord sur un environnement de test (ou un sous-domaine) avant bascule.
Perf
Une redirection ajoute un aller-retour réseau. Sur un tunnel (login/checkout), mesurez l’impact (TTFB / timings réseau).
Tester une redirection 307 (avant prod)
Objectif : vérifier le statut, l’en-tête Location, et l’absence de chaînes.
Avec curl (réponse brute)
# Voir les headers (statut + Location)
curl -I https://www.exemple.com/ancienne-route
# Suivre la redirection (utile pour détecter une chaîne)
curl -IL https://www.exemple.com/ancienne-routeAvec DevTools (navigateur)
- Ouvrez Network → cochez Disable cache.
- Rechargez la page → vérifiez Status (307) et Location.
- Sur une route sensible, testez un scénario réel (POST), pas une simple navigation.
Attention au cache
Certains comportements perçus “au navigateur” peuvent être influencés par le cache (navigateur, CDN, proxy).
Confirmez toujours au curl -I.
FAQ technique : 307 en production
Pour une maintenance d’API, faut-il privilégier une redirection 307 ou une 302 ?
Si vous devez conserver strictement la méthode (POST/PUT), la 307 est plus sûre.
Pour un cas “temporaire” sur des GET, une 302 suffit souvent.
En maintenance d’API, considérez aussi un 503 si l’objectif est de signaler
une indisponibilité plutôt qu’un déplacement temporaire.
Une redirection 307 prolongée peut-elle nuire au budget de crawl et au référencement ?
Oui : “temporaire” mais prolongée, une 307 pousse les bots à re-tester l’URL source
et chaque redirection coûte en crawl.
Si la situation devient durable, requalifiez en 301
(ou 308 si vous devez conserver la méthode).
Comment éviter qu’une 307 soit mise en cache trop agressivement (navigateur/CDN) ?
Réduisez les TTL côté CDN si nécessaire, et sur des routes critiques vous pouvez ajouter
des directives comme Cache-Control: no-store.
Ensuite, purgez le cache CDN après changement et testez en navigation privée + curl.
Quel est l’impact en latence d’une 307 serveur (Nginx/Apache) vs un 503 ?
Une 307 ajoute un aller-retour (le client suit Location).
Un 503 ne redirige pas mais peut déclencher des retries côté client/bot.
Le choix dépend du but : déplacement temporaire (307) ou indisponibilité (503).
Une redirection 307 d’une requête POST avec données sensibles crée-t-elle un risque spécifique ?
Le risque principal est l’open redirect (rediriger vers une destination non contrôlée)
et la casse de flux (cookies, session, CSRF).
Verrouillez la destination, logguez, et testez le parcours complet sur la méthode réelle.
Aller plus loin dans le cluster 307
🎯 Analyse IA de cet article
Obtenez un résumé expert et des insights SEO personnalisés
💡 Chaque IA apporte une perspective unique


