Hosting 動作をカスタマイズする

Firebase Hosting には、コンテンツをホストする方法をカスタマイズできる追加機能が用意されています。この記事ではカスタム エラーページ、リダイレクト、リライト、ヘッダーについて説明します。

カスタム 404 / Not Found ページ

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

404.html ページをプロジェクトのパブリック ディレクトリに追加すると、Firebase Hosting がユーザーに 404 Not Found エラーを表示する必要があるときに、404.html ページのコンテンツが表示されます。

リダイレクト

URL リダイレクトは、ページの移動や URL の短縮でリンクが無効にならないようにするために使用します。指定されたソース URL をブラウザで開こうとすると、代わりにリダイレクト先の URL が開かれ、ブラウザの場所がリダイレクト先の URL に更新されます。たとえば、example.com/teamexample.com/about.html にリダイレクトできます。

URL リダイレクトを指定するには、firebase.json ファイルの hosting 内で redirects セクションを定義します。

"hosting": {
  // Add the "redirects" section within "hosting"
  "redirects": [ {
    "source" : "/foo",
    "destination" : "/bar",
    "type" : 301
  }, {
    "source" : "/firebase/*",
    "destination" : "https://firebase.google.com",
    "type" : 302
  } ]
}

redirects 設定はリダイレクト ルールの配列を含むオプションのパラメータです。ルールごとに sourcedestinationtype を指定する必要があります。

source パラメータは、各リクエストの開始時(対象のパスにファイルまたはフォルダが存在するかどうかが確認される前)にすべての URL パスに対して照合される glob パターンです。一致するパスが見つかると、静的な destination 文字列で設定された Location ヘッダーを持つ HTTP リダイレクト レスポンスが設定されます。このヘッダーは相対パスまたは絶対 URL で指定できます。

最後に type パラメータで、表示する特定の HTTP レスポンス コードを指定します。「Moved Permanently」には 301 を指定し、「Found」(Temporary Redirect)には 302 を指定できます。

リライト

リライトは、複数の URL で同じコンテンツを表示するために使用します。パターンに一致する URL を受け取って、クライアント側コードで表示内容を決定するようにできるため、パターン マッチングで使用すると特に有用です。たとえば、リライトルールを使用して、ナビゲーションに HTML5 pushState を使用するアプリをサポートできます。指定されたソース URL をブラウザで開こうとすると、リライト先の URL にあるファイルのコンテンツが表示されます。

URL リライトを指定するには、firebase.json ファイルの hosting 内で rewrites セクションを定義します。

"hosting": {
  // Add the "rewrites" section within "hosting"
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

rewrites 設定は内部リライトルールの配列を含むオプションのパラメータです。前述の redirects と同様、リライトルールごとに source glob パターンとローカルの destination(実在のファイルでなければなりません)が必要です。指定された source にファイルまたはフォルダが存在しない場合、Firebase Hosting はリライトルールを適用し、HTTP リダイレクトの代わりに、指定された destination ファイルの実際のコンテンツを返します。

上の例では、フォルダにファイルが存在しない場合、リライトルールは /index.html のコンテンツを返します。これは、アプリで HTML5 pushState を使用する場合に便利です。

ヘッダー

カスタムのファイル固有ヘッダーを指定するには、firebase.json ファイルの hostingheaders セクションを定義します。

"hosting": {
  // Add the "headers" section within "hosting".
  "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"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source" : "404.html",
    "headers" : [ {
      "key" : "Cache-Control",
      "value" : "max-age=300"
    } ]
  } ]
}

headers 設定はカスタム ヘッダー定義の配列を含むオプションのパラメータです。定義ごとに source キーが必要であり、glob 表現を使用したリライトルールに関係なく、この値が元のリクエストパスと照合されます。また、定義ごとに、適用される headers の配列(それぞれ keyvalue を持つこと)も必要です。

前述の例では、すべてのフォント ファイルに CORS ヘッダーを指定し、画像ファイルについて 1 時間というデフォルト ブラウザ キャッシュを 2 時間のキャッシュでオーバーライドしています。以下のヘッダーは、headers 構成で設定することはできません。

  • Strict-Transport-Security
  • Public-Key-Pinning
  • Set-Cookie

使用可能なすべての構成オプションについては、デプロイ構成のリファレンスをご覧ください。

ホスティングの優先順位

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

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

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。