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

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

カスタム 404/Not Found ページ

ユーザーが存在しないページにアクセスしようとしたときに、カスタマイズした 404/Not Found エラーが表示されるように指定できます。404.html ページをプロジェクトのパブリック ディレクトリに追加するだけで、Firebase Hosting がユーザーに 404 Not Found エラーを表示する必要があるときに、このページのコンテンツが表示されます。

リダイレクト

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 パターンです。一致するパスが見つかると、HTTP リダイレクト レスポンスは、静的な destination 文字列(相対パスまたは絶対 URL で指定)に設定された 「Location」ヘッダーに設定されます。

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

リライト

リライトは複数の 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(実在のファイルである必要があります)が必要です。リライトルールは、指定されたソースにファイルまたはフォルダが存在しない場合にのみ適用され、HTTP リダイレクトする代わりに、転送先にあるファイルの実際のコンテンツを返します。

上記の例では、ファイルが存在しない場合に任意のフォルダ内の任意のファイルを /index.html にリライトしています。これは HTML5 pushState を利用しているアプリに便利です。

ヘッダー

firebase.json ファイルの hosting 内にある headers セクションを定義することで、カスタムのファイル固有ヘッダーを指定できます。

"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 時間のキャッシュでオーバーライドしています。現時点では次のヘッダーを key として使用できます。

  • Cache-Control
  • Access-Control-Allow-Origin
  • X-UA-Compatible
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
  • Content-Type
  • Link
  • Content-Security-Policy

使用可能なすべての設定オプションは、デプロイ設定のリファレンスでご覧いただけます。

ホスティングの優先順位

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

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

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

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