正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

GitLab Pagesリダイレクト

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

GitLab Pagesでは、NetlifyスタイルのHTTPリダイレクトを使用して、あるURLを別のURLに転送するルールを設定できます。

Netlifyが提供するすべての特別なオプションがサポートされているわけではありません。

機能サポート対象例
リダイレクト(301、302)check-circle 対応/wardrobe.html /narnia.html 302
リライト(200)check-circle 対応/* / 200
Splatcheck-circle 対応/news/* /blog/:splat
プレースホルダーcheck-circle 対応/news/:year/:month/:date /blog-:year-:month-:date.html
リライト（200以外）dotted-circle 対象外/en/* /en/404.html 404
クエリパラメータdotted-circle 対象外/store id=:id /blog/:id 301
強制 (シャドウイング)dotted-circle 対象外/app/ /app/index.html 200!
ドメインレベルのリダイレクトcheck-circle 対応http://blog.example.com/* https://www.example.com/blog/:splat 301
国または言語によるリダイレクトdotted-circle 対象外/ /anz 302 Country=au,nz
ロールによるリダイレクトdotted-circle 対象外/admin/* 200! Role=admin

マッチング動作テストケースは、GitLabがルールマッチングをどのように詳細に実装しているかを理解するための優れたリソースです。このテストケーススイートに含まれていないエッジケースに対するコミュニティからのコントリビュートをお待ちしています。

リダイレクトを作成

リダイレクトを作成するには、GitLab Pagesサイトのpublic/ディレクトリに_redirectsという名前の設定ファイルを作成します。

  • すべてのパスは、フォワードスラッシュ/で始まる必要があります。

  • ステータスコードが指定されていない場合、301のデフォルトのステータスコードが適用されます。

  • _redirectsファイルには、インスタンスレベルで設定された、ファイルサイズの制限とプロジェクトごとのルールの最大数があります。設定された最大数の中で最初に一致するルールのみが処理されます。デフォルトのファイルサイズの制限は64 KBで、デフォルトのルールの最大数は1,000です。

  • GitLab Pagesサイトがデフォルトのドメイン名（namespace.gitlab.io/project-slugなど）を使用している場合は、すべてのルールにパスをプレフィックスとして付ける必要があります:

    /project-slug/wardrobe.html /project-slug/narnia.html 302

  • GitLab Pagesサイトがカスタムドメインを使用している場合は、プロジェクトパスのプレフィックスは不要です。たとえば、カスタムドメインがexample.comの場合、_redirectsファイルは次のようになります:

    /wardrobe.html /narnia.html 302

ファイルはリダイレクトをオーバーライドします

ファイルはリダイレクトよりも優先されます。ファイルがディスク上に存在する場合、GitLab Pagesはリダイレクトの代わりにそのファイルを提供します。たとえば、hello.htmlとworld.htmlのファイルが存在し、_redirectsファイルに次の行が含まれている場合、hello.htmlが存在するため、リダイレクトは無視されます:

/project-slug/hello.html /project-slug/world.html 302

GitLabは、この動作を変更するためのNetlify force optionをサポートしていません。

HTTPステータスコード

ステータスコードが指定されていない場合は、301のデフォルトのステータスコードが適用されますが、独自のステータスコードを明示的に設定できます。次のHTTPコードがサポートされています:

  • 301: 永続的なリダイレクト。
  • 302: 一時的なリダイレクト。
  • 200: 成功したHTTPリクエストに対する標準的な応答。アドレスバーのURLを変更せずに、toルールにコンテンツが存在する場合、Pagesはそのコンテンツを提供します。

リダイレクト

リダイレクトを作成するには、fromパス、toパス、およびHTTPステータスコードを含むルールを追加します:

# 301 permanent redirect
/old/file.html /new/file.html 301

# 302 temporary redirect
/old/another_file.html /new/another_file.html 302

リライト

200のステータスコードを指定して、リクエストがfromに一致した場合にtoパスのコンテンツを提供します:

/old/file.html /new/file.html 200

このステータスコードは、Splatルールと組み合わせて使用​​して、URLを動的に書き換えることができます。

ドメインレベルのリダイレクト

ドメインレベルのリダイレクトを作成するには、ドメインレベルのパス（http://またはhttps://で始まる）を次のいずれかに追加します:

  • toパスのみ。
  • fromとtoのパス。

サポートされているHTTPステータスコードは、301と302です:

# 301 permanent redirect
http://blog.example.com/file_1.html https://www.example.com/blog/file_1.html 301
/file_2.html https://www.example.com/blog/file_2.html 301

# 302 temporary redirect
http://blog.example.com/file_3.html https://www.example.com/blog/file_3.html 302
/file_4.html https://www.example.com/blog/file_4.html 302

ドメインレベルのリダイレクトは、Splatルール（Splatプレースホルダーを含む）と組み合わせて使用​​して、URLパスを動的に書き換えることができます。

Splat

Splatとして知られる、そのfromパスにアスタリスク(*)を持つルールは、リクエストされたパスの先頭、中間、または末尾の何かに一致します。この例は、/old/の後の何かに一致し、/new/file.htmlに書き換えます:

/old/* /new/file.html 200

Splatプレースホルダー

ルールのfromパス内の*によって一致したコンテンツは、:splatプレースホルダーを使用してtoパスに挿入できます:

/old/* /new/:splat 200

この例では、/old/file.htmlへのリクエストは、200ステータスコードで/new/file.htmlのコンテンツを提供します。

ルールのfromパスに複数のSplatが含まれている場合、最初のSplat一致の値は、toパス内の:splatをすべて置き換えます。

Splatマッチング動作

Splatは「貪欲」であり、可能な限り多くの文字に一致します:

/old/*/file /new/:splat/file 301

この例では、ルールは/old/a/b/c/fileを/new/a/b/c/fileにリダイレクトします。

Splatは空の文字列にも一致するため、前のルールは/old/fileを/new/fileにリダイレクトします。

ルートindex.htmlへのすべてのリクエストを書き換えます

シングルページアプリケーション（SPA）は、クライアントサイドルートを使用して独自ルーティングを実行することがよくあります。これらのアプリケーションでは、ルーティングロジックをJavaScriptアプリケーションで処理できるように、ルートindex.htmlへのすべてのリクエストを書き換えます。

index.htmlへのリクエストを書き換えるには、次のようにします:

  1. この_redirectsルールを追加します:

    /* /index.html 200

  2. シングルページアプリケーションを並行デプロイで使用できるようにするには、リダイレクトルールを編集して、パスのプレフィックスを含めます:

    /project/base/<prefix>/* /project/base/<prefix>/index.html 200

    <prefix>をパスプレフィックス値に置き換えます。

プレースホルダー

ルールでプレースホルダーを使用して、リクエストされたURLの一部に一致させ、新しいURLへの書き換えまたはリダイレクト時にこれらのテストケースを使用します。

プレースホルダーは、:文字と、fromおよびtoのパスの両方の文字の文字列（[a-zA-Z]+）が続く形式でフォーマットされます:

/news/:year/:month/:date/:slug /blog/:year-:month-:date-:slug 200

このルールは、200で/blog/2021-08-12-file.htmlのコンテンツを提供することにより、/news/2021/08/12/file.htmlのリクエストに応答するようにPagesに指示します。

プレースホルダーマッチングの動作

Splatと比較して、プレースホルダーが一致するコンテンツの量は制限されています。プレースホルダーは、フォワードスラッシュ（/）の間のテキストに一致するため、プレースホルダーを使用して単一のパスセグメントを照合します。

さらに、プレースホルダーは空の文字列と一致しません。次のようなルールは、/old/fileのようなリクエストURLと一致not（しません）:

/old/:path /new/:path

リダイレクトルールのデバッグ

リダイレクトが期待どおりに機能しない場合、またはリダイレクト構文を検証する場合は、[your pages url]/_redirectsにアクセスしてください。_redirectsファイルは直接提供されませんが、ブラウザにはリダイレクトルールの番号付きリストと、ルールが有効か無効かが表示されます:

11 rules
rule 1: valid
rule 2: valid
rule 3: error: splats are not supported
rule 4: valid
rule 5: error: placeholders are not supported
rule 6: valid
rule 7: error: no domain-level redirects to outside sites
rule 8: error: url path must start with forward slash /
rule 9: error: no domain-level redirects to outside sites
rule 10: valid
rule 11: valid

Netlify実装との違い

サポートされているほとんどの_redirectsルールは、GitLabとNetlifyの両方で同じように動作します。ただし、いくつかの小さな違いがあります:

  • All rule URLs must begin with a slash（すべてのルールURLはスラッシュで始まる必要があります）:

    Netlifyでは、URLがフォワードスラッシュで始まる必要はありません:

    # Valid in Netlify, invalid in GitLab
*/path /new/path 200

    GitLabは、すべてのURLがフォワードスラッシュで始まることを検証します。前の例の有効な同等テストケース:

    # Valid in both Netlify and GitLab
/old/path /new/path 200

  • All placeholder values are populated（すべてのプレースホルダーの値が入力された）:

    Netlifyは、toパスに表示されるプレースホルダー値のみを入力されたします:

    /old /new/:placeholder

    /oldへのリクエストが指定されている場合:

    • Netlifyは/new/:placeholderにリダイレクトします（リテラルの:placeholderを使用）。
    • GitLabは/new/にリダイレクトします。