Location

Utilisation

Les serveurs incluent Location lorsqu’ils dirigent les clients vers une autre URL. L’en-tête apparaît dans deux contextes : les réponses de redirection et la création de ressources.

Pour les redirections, la valeur de Location indique au client où envoyer la requête suivante. Le comportement dépend du code de statut :

Pour la création de ressources, une réponse 201 Created inclut un Location pointant vers la ressource nouvellement créée. Le client dispose ainsi d’une référence directe, sans avoir besoin d’une recherche complémentaire.

La valeur de Location accepte aussi bien des URL absolues que relatives. Les URL relatives sont résolues par rapport à l’URI de la requête.

Remarque

L’en-tête Location et l’en-tête Content-Location remplissent des rôles différents. Location désigne la cible de la redirection ou la ressource nouvellement créée. Content-Location identifie l’URL directe de la représentation retournée.

Remarque

Les moteurs de recherche suivent les redirections et transfèrent le capital de liens (valeur de classement) vers l’URL cible lors des redirections permanentes (301, 308). Les redirections temporaires (302, 307) ne transmettent pas toujours ce capital de liens. Utiliser le bon code de statut lors des migrations d’URL préserve le classement dans les résultats de recherche.

URL

La valeur est une référence d’URI unique pointant vers l’emplacement cible.

Location: <url>

L’URL est soit un URI absolu comportant un schéma et un hôte, soit une référence relative résolue par rapport à l’URI de la requête.

Exemple

Une redirection permanente d’un ancien domaine vers un nouveau indique aux clients de mettre à jour signets et liens. Avec 301, les clients sont autorisés à changer la méthode de la requête de POST vers GET.

HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/products

Une redirection permanente 308 conserve la méthode de requête d’origine, ce qui rend la redirection sûre pour POST et les autres requêtes non-GET.

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.re/products

Après la création d’une ressource via une requête POST, le serveur renvoie 201 accompagné du Location de la nouvelle ressource.

HTTP/1.1 201 Created
Location: /api/orders/7891
Content-Type: application/json

Une réponse 303 après la soumission d’un formulaire redirige le client vers une page de résultats au moyen de GET.

HTTP/1.1 303 See Other
Location: /search/results?q=http+headers

Dépannage

Les échecs de redirection se manifestent souvent par des boucles infinies, des URL cassées ou des en-têtes absents de la réponse.

Boucle de redirection. L’en-tête Location renvoie vers l’URL courante, ou vers une autre URL qui redirige en retour, créant un cycle infini. Les navigateurs s’arrêtent au bout d’un nombre défini de sauts et affichent une erreur ERR_TOO_MANY_REDIRECTS. Tracez la chaîne avec curl -L -v pour repérer la boucle. Parmi les causes courantes : une règle serveur qui redirige HTTP vers HTTPS tandis qu’un répartiteur de charge redirige HTTPS vers HTTP, ou des règles nginx return 301 qui correspondent à l’URL de destination. Dans nginx, employez des gardes if ($scheme = http) de façon restrictive et testez avec les deux protocoles.

URL relative mal résolue. La valeur de Location accepte les références relatives, mais certains clients anciens et certains intermédiaires attendent une URL absolue. Un chemin comme /new-page est résolu par rapport à l’URI de la requête. Omettre la barre oblique initiale produit un chemin relatif résolu par rapport au répertoire courant, d’où des résultats inattendus. Utilisez des URL absolues avec schéma et hôte pour éviter toute ambiguïté.

En-tête Location absent d’une réponse 3xx. Un code de statut de redirection sans en-tête Location laisse le client sans destination. Les navigateurs affichent une page blanche ou une erreur. Contrôlez la réponse du serveur avec curl -I https://example.re/old-path et vérifiez la présence de l’en-tête. Dans Apache, les directives Redirect et RedirectMatch incluent toujours l’en-tête. Le code applicatif personnalisé doit le définir explicitement.

Incohérence de protocole dans la cible de redirection. Une URL HTTP dans l’en-tête Location sur un site HTTPS déclenche des avertissements de contenu mixte ou bloque la redirection dans les environnements stricts. Assurez-vous que l’URL cible correspond au protocole d’origine ou passe à HTTPS. Dans nginx, utilisez return 301 https://$host$request_uri; pour conserver le schéma sécurisé.

Fragment non conservé au fil des redirections. L’identifiant de fragment (#section) de l’URL d’origine n’est pas transmis dans l’en-tête Location. Les navigateurs rattachent le fragment d’origine à la cible de la redirection uniquement si l’URL cible ne contient pas elle-même de fragment. Si la valeur de Location comporte un fragment différent, l’original est perdu. Le code côté serveur n’a aucun accès aux fragments, puisque les navigateurs ne les envoient pas dans les requêtes.

Déboguer les chaînes de redirection. Lancez curl -L -v https://example.re/start pour suivre toutes les redirections et observer chaque saut avec ses codes de statut et ses en-têtes. L’onglet Network des DevTools affiche lui aussi la chaîne complète. Filtrez par type de document pour isoler les réponses de redirection des requêtes de sous-ressources.