ホスティング動作を構成する

Firebase Hosting を使用すると、サイトへのリクエストに対してカスタマイズされたホスティング動作を構成できます。

Hosting で何が構成できますか？

• ローカル プロジェクト ディレクトリにあるファイルの中から、Firebase Hosting にデプロイするファイルを指定します。詳しくはこちらをご覧ください。

• カスタマイズされた 404/Not Found ページを提供します。詳しくはこちらをご覧ください。

• 移動または削除したページの redirects を設定します。詳しくはこちらをご覧ください。

• 次の目的で rewrites を設定します。

  • 複数の URL で同じコンテンツを表示します。詳しくはこちらをご覧ください。

  • 関数を提供したり、Hosting URL から Cloud Run コンテナにアクセスしたりします。詳しくはこちらをご覧ください。関数またはコンテナ。

  • カスタム ドメインの Dynamic Link を作成します。詳しくはこちらをご覧ください。

• headers を追加して、リクエストまたはレスポンスに関する詳細情報を渡します。たとえば、ブラウザがページやコンテンツをどのように処理すべきかに関する情報を渡すことができます（認証、キャッシュ、エンコードなど）。詳しくはこちらをご覧ください。

• 国際化（i18n）リライトを設定し、ユーザーの言語設定または国に基づいて特定のコンテンツを提供します。詳しくはこちらをご覧ください（別のページに移動します）。

Hosting の構成を定義する場所

Firebase Hosting の構成は firebase.json ファイルで定義します。firebase init コマンドを実行すると、Firebase によってプロジェクト ディレクトリのルートに firebase.json ファイルが自動的に作成されます。

注意: firebase init を再度実行して Hosting を選択すると、firebase.json ファイルの hosting セクションが上書きされ、デフォルトの構成に戻されます。

このページの最後に、詳しい firebase.json の構成例（Firebase Hosting のみを対象）を紹介します。firebase.json ファイルには、他の Firebase サービスの構成も定義できます。

Hosting REST API を使用すると、デプロイされる firebase.json コンテンツを確認できます。

Hosting のレスポンスの優先順位

このページで説明する Firebase Hosting 構成オプションが競合する場合があります。競合が発生した場合、Hosting からのレスポンスは次の優先順位に従って決定されます。

1. /__/* パスセグメントで始まる予約済みの名前空間
2. リダイレクトの構成
3. 正確に一致する静的コンテンツ
4. リライトの構成
5. カスタムの 404 ページ
6. デフォルトの 404 ページ

重要: それぞれの redirects 属性と rewrites 属性の中で、Hostingリクエストされたパスと一致する URL パターンを持つ最初のルールで定義されているリダイレクトまたはリライトが適用されます。そのため、それぞれの redirects 属性とrewrites 属性の中でルールを意図的に並べる必要があります。構成済みの redirects は引き続き rewrites よりも優先されます。

i18n リライトを使用する場合は、スコープ内の完全一致と 404 処理の優先順位が拡張され、「i18n content」が含められます。

デプロイするファイルを指定する

デフォルトの firebase.json ファイルに含まれるデフォルトの属性（public と ignore）により、プロジェクト ディレクトリ内のどのファイルが Firebase プロジェクトにデプロイされるかが定義されます。

firebase.json ファイルのデフォルトの hosting 構成は次のようになります。

"hosting": {
  "public": "public",  // the only required attribute for Hosting
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
}

一般公開

必須
public 属性には、Firebase Hosting にデプロイするディレクトリを指定します。デフォルト値は public という名前のディレクトリですが、プロジェクト ディレクトリ内に存在している任意のディレクトリのパスを指定できます。

デプロイするディレクトリのデフォルト名は次のとおりです。

"hosting": {
  "public": "public"

  // ...
}

デフォルト値は、デプロイするディレクトリに変更できます。

"hosting": {
  "public": "dist/app"

  // ...
}

無視

省略可
ignore 属性には、デプロイ時に無視するファイルを指定します。Git の .gitignore と同じように glob を使用できます。

無視するファイルのデフォルト値は次のとおりです。

"hosting": {
  // ...

  "ignore": [
    "firebase.json",  // the Firebase configuration file (the file described on this page)
    "**/.*",  // files with a leading period should be hidden from the system
    "**/node_modules/**"  // contains dependencies used to create your site but not run it
  ]
}

404 / Not Found ページをカスタマイズする

省略可
存在しないページにユーザーがアクセスしようとしたときに、カスタム 404 Not Found エラーを表示するように指定できます。

プロジェクトの public ディレクトリに新しいファイルを作成し、404.html という名前を付けて、カスタムの 404 Not Found コンテンツをそのファイルに追加します。

ブラウザでドメインまたはサブドメインに 404 Not Found エラーが発生した場合、Firebase Hosting はこのカスタム 404.html ページのコンテンツを表示します。

リダイレクトを構成する

省略可
URL リダイレクトは、ページの移動や URL の短縮でリンクが無効にならないようにするために使用します。たとえば、ブラウザを example.com/team から example.com/about.html にリダイレクトできます。

URL リダイレクトを指定するには、オブジェクトの配列を含む redirects 属性を作成します（「リダイレクト ルール」と呼ばれます）。それぞれのルールで URL パターンを指定します。この URL パターンがリクエスト URL パスと一致した場合、指定された　Hosting　宛先 URL へのリダイレクトの応答がトリガーされます。

redirects 属性の基本構造は次のとおりです。この例では、/foo に対するリクエストをリダイレクトし、新しいリクエストを /bar に送信します。

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

redirects 属性の詳しい例を見る

"hosting": {
  // ...

  // Add the "redirects" attribute within "hosting"
  "redirects": [ {
    // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  }, {
    // Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
    "source": "/foo{,/**}"
    "destination": "/bar"
    "type": 301
  }, {
    // Returns a temporary redirect for all requests to files or directories in the "firebase" directory
    "source": "/firebase/**",
    "destination": "https://firebase.google.com/",
    "type": 302
  }, {
    // A regular expression-based redirect equivalent to the above behavior
    "regex": "/firebase/.*",
    "destination": "https://firebase.google.com/",
    "type": 302
  } ]
}

redirects 属性にはリダイレクト ルールの配列が含まれます。それぞれのルールには、以下の表に示すフィールドを含める必要があります。

Firebase Hosting は、各リクエストの開始時（ファイルまたはフォルダがそのパスに存在するかどうかをブラウザが判断する前）に source または regex の値とすべての URL パスを比較します。一致が見つかった場合、Firebase Hosting のオリジン サーバーが HTTPS リダイレクト レスポンスを送信し、destination URL に新しいリクエストを送信するようにブラウザに指示します。

フィールド		説明
redirects
	source （推奨） または regex	URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、Hosting　リダイレクトの適用がトリガーされます。 source を使用して glob を指定します（推奨）。 regex を使用して RE2 正規表現を指定します。
	destination	ブラウザが新しいリクエストを送信する静的 URL この URL には、相対パス、絶対パスのどちらでも指定できます。
	type	HTTPS レスポンス コード 「Moved Permanently（恒久的に移動した）」には 301 のタイプを使用します。 「Found（検出）」（一時的なリダイレクト）には 302 のタイプを使用します。

重要: redirects 属性の中で、リクエストされたパスと一致する URL パターンを持つ最初のルールで定義されている　Hosting　リダイレクトが適用されます。そのため、redirects 属性の中でルールを意図的に並べる必要があります。

リダイレクト用の URL セグメントをキャプチャする

省略可
リダイレクト ルールの URL パターン（source または regex の値）の特定のセグメントをキャプチャし、ルールの destination パスでそれらのセグメントを使用しなければならない場合があります。

glob を使用する場合の URL セグメントのキャプチャ

source フィールドを使用している場合（つまり URL パターンに glob を指定している場合）、セグメントを識別するための : プレフィックスを含めることによって、セグメントをキャプチャできます。セグメントの後の残りの URL パスもキャプチャする必要がある場合は、セグメントの直後に * を使用します。次に例を示します。

"hosting": {
  // ...

  "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and captured by the "source" value
    "type": 301
  } ]
}

RE2 正規表現を使用する場合の URL セグメントのキャプチャ

regex フィールドを使用している場合（つまり URL パターンに RE2 正規表現を指定している場合）、名前付きまたは名前なしの RE2 キャプチャ グループを使用してセグメントをキャプチャできます。名前付きキャプチャ グループは、destination フィールド内で : プレフィックスを使用することによって参照できます。名前なしキャプチャ グループは、regex の値の数字インデックスで参照できます（このインデックスは 1 から始まります）。次に例を示します。

"hosting": {
  // ...

  "redirects": [ {
    "regex": "/blog/(?P<post>.+)",  // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P
    "destination": "https://blog.myapp.com/:post",  // includes the entire URL segment identified and captured by the `regex` value
    "type": 301
  }, {
    "regex": "/users/(\d+)/profile",  // uses the \d directive to only match numerical path segments
    "destination": "/users/:1/newProfile",  // the first capture group to be seen in the `regex` value is named 1, and so on
    "type": 301
  } ]
}

リライトを構成する

省略可
リライトは、複数の URL で同じコンテンツを表示するために使用します。パターンに一致する URL を受け取って、クライアント側コードで表示内容を決定するようにできるため、パターン マッチングで使用すると特に有用です。

リライトを使用すると、ナビゲーションに HTML5 pushState を使用するアプリをサポートできます。指定した source または regex の URL パターンに一致する URL パスをブラウザが開こうとすると、代わりに destination URL のファイルのコンテンツが表示されます。

URL リライトを指定するには、オブジェクトの配列を含む rewrites 属性を作成します（「リライトルール」と呼ばれます）。それぞれのルールで URL パターンを指定します。この URL パターンがリクエスト URL パスと一致した場合、Hosting の応答がトリガーされ、指定された宛先 URL を提供するように応答が行われます。

rewrites 属性の基本構造は次のとおりです。この例では、存在しないファイルまたはディレクトリへのリクエストに対して index.html を返します。

"hosting": {
  // ...

  // Serves index.html for requests to files or directories that do not exist
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

rewrites 属性の詳しい例を見る

"hosting": {
// ...

// Add the "rewrites" attribute within "hosting"
"rewrites": [ {
  // Serves index.html for requests to files or directories that do not exist
  "source": "**",
  "destination": "/index.html"
}, {
  // Serves index.html for requests to both "/foo" and "/foo/**"
  // Using "/foo/**" only matches paths like "/foo/xyz", but not "/foo"
  "source": "/foo{,/**}",
  "destination": "/index.html"
}, {
  // A regular expression-based rewrite equivalent to the above behavior
  "regex": "/foo(/.*)?",
  "destination": "/index.html"
}, {
  // Excludes specified pathways from rewrites
  "source": "!/@(js|css)/**",
  "destination": "/index.html"
} ]
}

rewrites 属性にはリライトルールの配列が含まれます。それぞれのルールには、以下の表に示すフィールドを含める必要があります。

Firebase Hosting は、指定された source または regex の URL パターンに一致する URL パスにファイルまたはディレクトリが存在しない場合にのみ、リライトルールを適用します。リクエストによってリライトルールがトリガーされると、ブラウザは HTTP リダイレクトではなく、指定された destination ファイルの実際のコンテンツを返します。

フィールド		説明
rewrites
	source （推奨） または regex	URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、Hosting　リライトの適用がトリガーされます。 source を使用して glob を指定します（推奨）。 regex を使用して RE2 正規表現を指定します。
	destination	実際に存在するローカル ファイル この URL には、相対パス、絶対パスのどちらでも指定できます。

重要: rewrites 属性内で、リクエストされたパスに一致する URL パターンを持つ最初のルールで定義されている　Hosting　リライトが適用されます。そのため、rewrites 属性の中でルールを意図的に並べる必要があります。

関数にリクエストを送信する

rewrites を使用して、Firebase Hosting URL から関数を提供できます。次のコードは、Cloud Functions を使用した動的コンテンツの配信から抜粋しています。

たとえば、Hosting サイトの /bigben ページからすべてのリクエストを送信して bigben 関数を実行する場合は、次のようになります。

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": {
      "functionId": "bigben",
      "region": "us-central1"  // optional (see note below)
      "pinTag": true           // optional (see note below)
    }
  } ]
}

function ブロック内の region の動作

hosting.rewrites 構成の function ブロックに region を含めないと、Firebase CLI は関数のソースコードからリージョンを自動的に検出しようとします（指定されていない場合のデフォルトは us-central1 です）。関数のソースコードを参照できない場合、CLI はデプロイされた関数からリージョンの検出を試みます。関数が複数のリージョンにある場合は、hosting.rewrites の構成内に region を指定する必要があります。

function ブロック内の pinTag の動作

pinTag の機能は、Cloud Functions for Firebase（第 2 世代）でのみ使用できます。この機能を使用すると、サイトの動的コンテンツを生成する各関数と、Hosting の静的なリソースや　Hosting　構成との同期を維持できます。また、この機能を使用して、Hosting プレビュー チャネル上の関数に対するリライトをプレビューできます。

hosting.rewrites 構成の function ブロックに "pinTag": true を追加すると、Hosting の静的なリソースや構成とともに、「固定された」関数がデプロイされます。この動作は firebase deploy --only hosting の実行時も行われます。サイトの特定のバージョンをロールバックすると、「固定された」関数もロールバックされます。

注: pinTag を既存のリライトに追加する場合は、まず更新されたリライトを「ライブ」チャネルにデプロイする必要があります。デプロイ後は、本番環境に影響を及ぼすことなく、Hosting プレビュー チャネルで関数のコードの変更をプレビューできます。

この機能は Cloud Run タグに依存しており、1 つのサービスで 1,000 タグ、1 つのリージョンで 2,000 タグという上限があります。したがって、何百回もデプロイを行うと、サイトの最も古いバージョンが動作しなくなることがあります。

このリライトルールを追加して Firebase にデプロイすると（firebase deploy を使用）、次の URL から関数にアクセスできるようになります。

• Firebase のサブドメイン:
  PROJECT_ID.web.app/bigben と PROJECT_ID.firebaseapp.com/bigben

• 接続されたカスタム ドメイン:
  CUSTOM_DOMAIN/bigben

Hosting を使用してリクエストを関数にリダイレクトする場合、サポートされている HTTP リクエスト メソッドは、GET、POST、HEAD、PUT、DELETE、PATCH、OPTIONS です。 REPORT や PROFIND などの他のメソッドはサポートされていません。

Cloud Run コンテナにリクエストをダイレクトする

rewrites を使用して、Firebase Hosting URL から Cloud Run コンテナにアクセスできます。次の例は、Cloud Run を使用した動的コンテンツの配信から抜粋しています。

たとえば、Hosting サイトの　/helloworld　ページからのすべてのリクエストを送信して、helloworld コンテナ インスタンスの起動と実行をトリガーする場合は、次のようにします。

"hosting": {
 // ...

 // Directs all requests from the page `/helloworld` to trigger and run a `helloworld` container
 "rewrites": [ {
   "source": "/helloworld",
   "run": {
     "serviceId": "helloworld",  // "service name" (from when you deployed the container image)
     "region": "us-central1"  // optional (if omitted, default is us-central1)
   }
 } ]
}

run ブロック内の pinTag の動作

この機能を使用すると、サイトの動的コンテンツを生成する Cloud Run サービスのリビジョンと、Hosting の静的なリソースや Hosting 構成との同期を維持できます。また、この機能を使用して、Hosting プレビュー チャネル上の Cloud Run に対するリライトをプレビューできます。

hosting.rewrites 構成の run ブロックに "pinTag": true を追加すると、デプロイ時に、Cloud Run サービスの最新のリビジョンに Hosting の静的なリソースと構成が固定されます。サイトの特定のバージョンをロールバックすると、「固定された」Cloud Run サービスのリビジョンもロールバックされます。

この機能は Cloud Run タグに依存しており、1 つのサービスで 1,000 タグ、1 つのリージョンで 2,000 タグという上限があります。したがって、何百回もデプロイを行うと、サイトの最も古いバージョンが動作しなくなることがあります。

このリライトルールを追加して Firebase にデプロイすると（firebase deploy を使用）、次の URL からコンテナ イメージにアクセスできるようになります。

• Firebase のサブドメイン:
  PROJECT_ID.web.app/helloworld と PROJECT_ID.firebaseapp.com/helloworld

• 接続されたカスタム ドメイン:
  CUSTOM_DOMAIN/helloworld

Hosting を使用してリクエストを Cloud Run コンテナにリダイレクトする場合、サポートされている HTTP リクエスト メソッドは、GET、POST、HEAD、PUT、DELETE、PATCH、OPTIONS です。REPORT や PROFIND などの他のメソッドはサポートされていません。

最適なパフォーマンスを得るには、次のリージョンを使用して、Cloud Run サービスを Hosting と同じ場所に配置します。

• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

Hosting から Cloud Run へのリライトは、次のリージョンでサポートされています。

• asia-east1
• asia-east2
• asia-northeast1
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-south2
• asia-southeast1
• asia-southeast2
• australia-southeast1
• australia-southeast2
• europe-central2
• europe-north1
• europe-southwest1
• europe-west1
• europe-west12
• europe-west2
• europe-west3
• europe-west4
• europe-west6
• europe-west8
• europe-west9
• me-central1
• me-west1
• northamerica-northeast1
• northamerica-northeast2
• southamerica-east1
• southamerica-west1
• us-central1
• us-east1
• us-east4
• us-east5
• us-south1
• us-west1
• us-west2
• us-west3
• us-west4
• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

カスタム ドメイン Dynamic Links を作成する

rewrites を使用して、カスタム ドメイン Dynamic Links を作成できます。Dynamic Links にカスタム ドメインを設定する方法については、Dynamic Links のドキュメントをご覧ください。

• Dynamic Links にのみカスタム ドメインを使用する

  "hosting": {
    // ...
  
    "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)
  
    // Add the "rewrites" attribute within "hosting"
    "rewrites": [ {
      "source": "/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/"
      "dynamicLinks": true
    } ]
  }

• Dynamic Links に使用するカスタム ドメインのパス接頭辞を指定する

  "hosting": {
    // ...
  
    "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)
  
    // Add the "rewrites" attribute within "hosting"
    "rewrites": [ {
      "source": "/promos/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/promos/"
      "dynamicLinks": true
    }, {
      "source": "/links/share/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/links/share/"
      "dynamicLinks": true
    } ]
  }

firebase.json ファイルに Dynamic Links を構成するには、次のことを行う必要があります。

フィールド		説明
appAssociation		AUTO に設定する必要があります。 この属性を構成に追加しないと、appAssociation のデフォルトは AUTO になります。 この属性を AUTO に設定すると、Hosting はリクエスト時に assetlinks.json ファイルと apple-app-site-association ファイルを動的に生成できます。
rewrites
	source	Dynamic Links に使用するパス URL のパスを書き換えるルールとは異なり、Dynamic Links の書き換えルールに正規表現を含めることはできません。
	dynamicLinks	true に設定する必要があります。

重要: Dynamic Links では、ホスティングの優先順位に注意する必要があります。

• Dynamic Links プレフィックスは、それよりも優先度の高いホスティング構成と競合しないようにします。たとえば、ホストされる静的コンテンツは必ずリライトよりも優先されます。
• redirects と rewrites の各属性内で、Hosting は、リクエストされたパスと一致する URL パターンを持つ最初のルールで定義されているリダイレクトまたはリライトを適用します。そのため、それぞれの redirects 属性と rewrites 属性の中でルールを意図的に並べる必要があります。

詳細については、Dynamic Links のドキュメントをご覧ください。

ヘッダーを構成する

省略可
ヘッダーを使用すると、クライアントとサーバーはリクエストまたはレスポンスと一緒に追加情報を渡すことができます。ヘッダーの一部は、ブラウザがページとそのコンテンツを処理する方法（アクセス制御、認証、キャッシュ、エンコードなど）に影響を与える可能性があります。

ファイル固有のカスタム レスポンス ヘッダーを指定するには、ヘッダー オブジェクトの配列を含む headers 属性を作成します。各オブジェクトに URL パターンを指定します。この URL パターンがリクエスト URL のパスと一致した場合、指定された　Hosting　カスタム レスポンス ヘッダーを適用するようにトリガーされます。

headers 属性の基本構造は次のとおりです。この例では、すべてのフォント ファイルに CORS ヘッダーを適用します。

"hosting": {
  // ...

  // Applies a CORS header for all font files
  "headers": [ {
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  } ]
}

headers 属性の詳しい例を見る

"hosting": {
  // ...

  // Add the "headers" attribute within "hosting"
  "headers": [ {
    // Applies a CORS header for all font files
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  }, {
    // Overrides the default 1 hour browser cache with a 2 hour cache for all image files
    "source": "**/*.@(jpg|jpeg|gif|png)",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // A regular expression-based rewrite equivalent to the above behavior
    "regex": ".+/\w+\.(jpg|jpeg|gif|png)$",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source": "404.html",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=300"
    } ]
  } ]
}

headers 属性には定義の配列が含まれます。それぞれの定義には、以下の表に示すフィールドを含める必要があります。

フィールド			説明
headers
	source （推奨） または regex		URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、Hosting　カスタム ヘッダーの適用がトリガーされます。 source を使用して glob を指定します（推奨）。 regex を使用して RE2 正規表現を指定します。 カスタム 404 ページに対して照合されるヘッダーを作成するには、source または regex の値として 404.html を使用します。
	（sub-）headers の配列		Hosting　リクエストパスに適用されるカスタム ヘッダー それぞれのサブヘッダーには key と value のペアを含める必要があります（次の 2 行を参照）。
		key	ヘッダーの名前。例: Cache-Control
		value	ヘッダーの値。例: max-age=7200

注: カスタム ヘッダーの URL パターンの一致は、リライトルールが適用される前に行われます。

Cache-Control について詳しくは、動的コンテンツの提供とマイクロサービスのホスティングについて説明する Hosting セクションをご覧ください。また、CORS ヘッダーの詳細も確認してください。

重要: Firebase Hosting は、デフォルトの Hosting サブドメイン（*.web.app など）の Strict-Transport-Security 構成を上書きします。ただし、接続されたカスタム ドメインはいずれも構成された値を提供します。

.html 拡張子を制御する

省略可
cleanUrls 属性を使用すると、URL に .html 拡張子を含めるかどうかを制御できます。

true の場合、Hosting はアップロードされたファイルの URL から拡張子 .html を自動的に削除します。.html 拡張子がリクエストに追加された場合、Hosting は同じパスへの 301 リダイレクトを実行しますが、.html 拡張子は削除されます。

cleanUrls 属性を使用して、URL に含まれる .html を制御する方法を次に示します。

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

末尾のスラッシュを制御する

省略可
trailingSlash 属性を使用すると、静的コンテンツの URL に末尾のスラッシュを含めるかどうかを制御できます。

• true の場合、Hosting は URL のリダイレクトで末尾のスラッシュを追加します。
• false の場合、Hosting は URL のリダイレクトで末尾のスラッシュを削除します。
• 指定しない場合、Hosting はディレクトリ インデックス ファイル（たとえば、about/index.html）にのみ末尾にスラッシュを追加します。

trailingSlash 属性を追加して末尾のスラッシュを制御する方法を次に示します。

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

trailingSlash 属性は、Cloud Functions または Cloud Run によって提供される動的コンテンツへのリライトには影響しません。

glob パターン マッチング

Firebase Hosting 構成オプションでは、Git で gitignore ルールを処理する場合や Bower で ignore ルールを処理する場合と同様に、extglob を使用する glob パターン マッチング表記を使用します。より詳しい参考資料としては、こちらの Wiki ページをご覧ください。以下では、このページで使用した例について説明します。

• firebase.json - public ディレクトリのルートにある firebase.json ファイルにのみ一致します。

• ** - 任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。

• * - public ディレクトリのルートにあるファイルとフォルダにのみ一致します。

• **/.* - 任意のサブディレクトリ内にある「.」で始まるファイル（通常は .git フォルダ内などにある非表示ファイル）と一致します。

• **/node_modules/** - node_modules フォルダの任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。このフォルダ自体が public ディレクトリの任意のサブディレクトリとなります。

• **/*.@(jpg|jpeg|gif|png) - 任意のサブディレクトリ内にあるファイルで、.jpg、.jpeg、.gif、.png のいずれかで終了するものと一致します。

Hosting の完全な構成例

Firebase Hosting の完全な firebase.json 構成例を次に示します。firebase.json ファイルには、他の Firebase サービスの構成も定義できます。

{
  "hosting": {

    "public": "dist/app",  // "public" is the only required attribute for Hosting

    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],

    "redirects": [ {
      "source": "/foo",
      "destination": "/bar",
      "type": 301
    }, {
      "source": "/firebase/**",
      "destination": "https://www.firebase.com",
      "type": 302
    } ],

    "rewrites": [ {
      // Shows the same content for multiple URLs
      "source": "/app/**",
      "destination": "/app/index.html"
    }, {
      // Configures a custom domain for Dynamic Links
      "source": "/promos/**",
      "dynamicLinks": true
    }, {
      // Directs a request to Cloud Functions
      "source": "/bigben",
      "function": "bigben"
    }, {
      // Directs a request to a Cloud Run containerized app
      "source": "/helloworld",
      "run": {
        "serviceId": "helloworld",
        "region": "us-central1"
      }
    } ],

    "headers": [ {
      "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
      "headers": [ {
        "key": "Access-Control-Allow-Origin",
        "value": "*"
      } ]
    }, {
      "source": "**/*.@(jpg|jpeg|gif|png)",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=7200"
      } ]
    }, {
      "source": "404.html",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=300"
      } ]
    } ],

    "cleanUrls": true,

    "trailingSlash": false,

    // Required to configure custom domains for Dynamic Links
    "appAssociation": "AUTO",

  }
}