Location

使い方

サーバーは、クライアントを別の URL へ誘導するときに Location を含めます。このヘッダーは 2 つの文脈で現れます。リダイレクトのレスポンスと、リソースの作成です。

リダイレクトでは、Location の値が次のリクエストをどこへ送るかをクライアントに伝えます。挙動はステータスコードによって異なります。

リソースの作成では、201 Created のレスポンスに、新規作成されたリソースを指す Location が含まれます。これにより、クライアントは改めて検索することなく直接の参照を得られます。

Location の値は絶対 URL と相対 URL のどちらも受け付けます。相対 URL はリクエスト URI を基準に解決されます。

注意

Location ヘッダーと Content-Location ヘッダーは異なる目的を持ちます。Location はリダイレクト先または新規作成されたリソースを指します。Content-Location は、返された表現の直接の URL を識別します。

注意

検索エンジンはリダイレクトをたどり、恒久的なリダイレクト（301、308）ではリンクエクイティ（ランキング上の価値）を遷移先の URL へ引き継ぎます。一時的なリダイレクト（302、307）は必ずしもリンクエクイティを渡しません。URL の移行時に正しいステータスコードを使うことで、検索順位が維持されます。

URL

値は、遷移先の場所を指す単一の URI 参照です。

Location: <url>

URL は、スキームとホストを含む絶対 URI か、リクエスト URI を基準に解決される相対参照のいずれかです。

例

旧ドメインから新ドメインへの恒久的なリダイレクトは、ブックマークやリンクを更新するようクライアントに伝えます。301 では、クライアントがリクエストメソッドを POST から GET に変更することが許されます。

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

308 の恒久的なリダイレクトは元のリクエストメソッドを保持するため、POST やその他の GET 以外のリクエストでも安全に使えます。

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

POST リクエストでリソースを作成した後、サーバーは新しいリソースの Location とともに 201 を返します。

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

フォーム送信後の 303 レスポンスは、GET を使って結果ページへクライアントをリダイレクトします。

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

トラブルシューティング

リダイレクトの失敗は、無限ループ、壊れた URL、レスポンスでのヘッダー欠落として現れることがよくあります。

リダイレクトループ。Location ヘッダーが現在の URL を指し返しているか、戻るようにリダイレクトする別の URL を指しており、無限の循環が生じています。ブラウザは一定のホップ数で停止し、ERR_TOO_MANY_REDIRECTS エラーを表示します。curl -L -v で連鎖をたどり、ループを特定してください。よくある原因は、サーバーの規則が HTTP を HTTPS へリダイレクトする一方でロードバランサーが HTTPS を HTTP へ戻している、あるいは nginx の return 301 の規則が遷移先 URL にも一致している、といったものです。nginx では if ($scheme = http) のガードを狭い範囲で使い、両方のプロトコルでテストしてください。

相対 URL が正しく解決されない。Location の値は相対参照を受け付けますが、一部の古いクライアントや中間装置は絶対 URL を期待します。/new-page のようなパスはリクエスト URI を基準に解決されます。先頭のスラッシュを省くと現在のディレクトリを基準に解決される相対パスになり、想定外の結果を招きます。曖昧さを避けるには、スキームとホストを含む絶対 URL を使ってください。

3xx レスポンスに Location ヘッダーがない。リダイレクトのステータスコードに Location ヘッダーが伴わないと、クライアントには遷移先がありません。ブラウザは空のページやエラーを表示します。curl -I https://example.re/old-path でサーバーのレスポンスを確認し、ヘッダーが存在することを確かめてください。Apache では Redirect と RedirectMatch のディレクティブが常にこのヘッダーを含めます。独自のアプリケーションコードでは、明示的にヘッダーを設定する必要があります。

リダイレクト先のプロトコルが一致しない。HTTPS のサイトで Location ヘッダーに HTTP の URL を入れると、混在コンテンツの警告が出たり、厳格な環境ではリダイレクトがブロックされたりします。遷移先の URL が発信元のプロトコルと一致するか、HTTPS へ引き上げられるようにしてください。nginx では return 301 https://$host$request_uri; を使ってセキュアなスキームを維持します。

リダイレクトをまたいでフラグメントが保持されない。元の URL のフラグメント識別子（#section）は Location ヘッダーで転送されません。ブラウザが元のフラグメントをリダイレクト先に付け直すのは、遷移先の URL が自前のフラグメントを持たない場合に限られます。Location の値が異なるフラグメントを含む場合、元のフラグメントは失われます。ブラウザはリクエストでフラグメントを送らないため、サーバー側のコードからフラグメントにアクセスすることはできません。

リダイレクトの連鎖をデバッグする。curl -L -v https://example.re/start を実行すると、すべてのリダイレクトをたどり、各ホップのステータスコードとヘッダーを確認できます。DevTools の Network タブでも連鎖全体を確認できます。ドキュメントの種類でフィルタリングすると、サブリソースのリクエストからリダイレクトのレスポンスを切り分けられます。