GitLab Pagesリダイレクト

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

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

リダイレクトを作成する

リダイレクトを作成するには、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の強制オプションをサポートしていません。

HTTPステータスコード

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

• 301: 恒久的なリダイレクト。
• 302: 一時的なリダイレクト。
• 200: 成功したHTTPリクエストに対する標準レスポンス。toルール内のコンテンツが存在する場合、アドレスバーのURLを変更せずに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

リライト

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

/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

fromパスにアスタリスク (*) が含まれるルール (これはSplatとして知られています) は、リクエストされたパスの先頭、途中、または末尾の任意の項目と一致します。この例では、/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パス内のすべての:splatsを置き換えます。

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

このルールは、/news/2021/08/12/file.htmlへのリクエストに対し、/blog/2021-08-12-file.htmlのコンテンツを200で提供するように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:

  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/にリダイレクトします。