設定託管行為

使用 Firebase Hosting 時，您可以為網站的要求設定自訂代管行為。

您可以為 Hosting 設定哪些項目？

• 指定要部署至 Firebase Hosting 的本機專案目錄中的檔案。瞭解詳情。

• 提供自訂的 404/找不到頁面。瞭解詳情。

• 針對已移動或刪除的網頁設定 redirects。瞭解詳情。

• 設定 rewrites 以用於下列任一用途：

  • 透過多個網址顯示相同內容。瞭解如何操作。

  • 透過 Hosting 網址提供函式或存取 Cloud Run 容器。瞭解如何：函式或容器。

  • 建立自訂網域 Dynamic Link。瞭解詳情。

• 新增 headers 可傳遞有關要求或回應的額外資訊，例如瀏覽器應如何處理網頁及其內容 (驗證、快取、編碼等)。瞭解詳情。

• 設定國際化 (i18n) 重寫功能，根據使用者的語言偏好和/或國家/地區，提供特定內容。瞭解如何 (不同頁面)。

您在哪裡定義 Hosting 設定？

您可以在 firebase.json 檔案中定義 Firebase Hosting 設定。執行 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 會套用由 first 規則定義的重新導向或重寫，並使用與要求路徑相符的網址模式。因此，您必須有意識地為每個 redirects 和 rewrites 屬性中的規則排序。已設定的 redirects 仍優先於 rewrites。

如果您使用i18n 重寫，則會擴大完全比對和 404 處理優先順序的範圍，以便納入「i18n 內容」。

指定要部署的檔案

預設 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 屬性會指定要忽略的部署檔案。它可以採用glob，就像 Git 處理 .gitignore 一樣。

以下是忽略檔案的預設值：

"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/找不到頁面

選用
當使用者嘗試存取不存在的頁面時，您可以提供自訂 404 Not Found 錯誤。

在專案的 public 目錄中建立新檔案，並將其命名為 404.html，然後將自訂 404 Not Found 內容新增至檔案。

如果瀏覽器在網域或子網域中觸發 404 Not Found 錯誤，Firebase Hosting 就會顯示這個自訂 404.html 頁面的內容。

設定重新導向

選用
如果您已移動網頁，或想縮短網址，請使用網址重新導向功能來避免出現無效連結。舉例來說，您可以將瀏覽器從 example.com/team 重新導向至 example.com/about.html。

如要指定網址重新導向，請建立包含物件陣列 (稱為「重新導向規則」) 的 redirects 屬性。在每個規則中指定網址模式，如果與要求網址路徑相符，就會觸發 Hosting 以回應重新導向至指定的目的網址。

以下是 redirects 屬性的基本結構。這個範例會透過向 /bar 提出新要求，將要求重新導向至 /foo。

"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 值與所有網址路徑進行比較。如果找到相符項目，Firebase Hosting 原始伺服器就會傳送 HTTPS 重新導向回應，告知瀏覽器在 destination 網址上提出新要求。

欄位		說明
redirects
	source (建議) or regex	網址模式，如果與初始要求網址相符，就會觸發 Hosting 套用重新導向 使用 source 指定 glob(建議做法)。 使用 regex 指定 RE2 規則運算式。
	destination	瀏覽器應提出新要求的靜態網址 這個網址可以是相對路徑或絕對路徑。
	type	HTTPS 回應代碼 使用 301 類型來表示「永久移除」 使用 302 類型表示「已找到」(暫時重新導向)

重要事項： 在 redirects 屬性中，Hosting 會套用 first 規則定義的重新導向，並使用與要求路徑相符的網址模式。因此，您必須有意在 redirects 屬性中排序規則。

擷取重新導向的網址區段

選用
有時您可能需要擷取重新導向規則網址模式的特定區段 (source 或 regex 值)，然後在規則的 destination 路徑中重複使用這些區段。

使用 glob 時擷取網址區段

如果您使用 source 欄位 (也就是為網址模式指定 glob)，您可以加入 : 前置字串來識別區隔，進而擷取區隔。如果您也需要擷取區段後方的剩餘網址路徑，請在區段後方立即加入 *。例如：

"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 規則運算式時擷取網址片段

如果您使用 regex 欄位 (也就是為網址模式指定 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
  } ]
}

設定重寫

選用
使用重寫功能，為多個網址顯示相同內容。重寫功能在比對模式時特別實用，因為您可以接受任何符合模式的網址，並讓用戶端程式碼決定要顯示的內容。

您也可以使用重寫功能，支援使用 HTML5 pushState 進行導覽的應用程式。當瀏覽器嘗試開啟符合指定 source 或 regex 網址模式的網址路徑時，瀏覽器會改為取得 destination 網址的檔案內容。

如要指定網址重寫作業，請建立包含物件陣列 (稱為「重寫規則」) 的 rewrites 屬性。在每個規則中指定網址模式，如果與要求網址路徑相符，就會觸發 Hosting 回應，就像服務收到指定的目的網址一樣。

以下是 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 網址模式時，才套用重寫規則。當要求觸發重寫規則時，瀏覽器會傳回指定 destination 檔案的實際內容，而不是 HTTP 重新導向。

欄位		說明
rewrites
	source (建議) or regex	網址模式，如果與初始要求網址相符，就會觸發 Hosting 套用重寫 使用 source 指定 glob(建議做法)。 使用 regex 指定 RE2 規則運算式。
	destination	必須存在的本機檔案 這個網址可以是相對路徑或絕對路徑。

重要事項： 在 rewrites 屬性中，Hosting 會套用「first」 規則定義的重寫作業，並使用與要求路徑相符的網址模式。因此，您必須有意在 rewrites 屬性中排序規則。

將要求直接傳送至函式

您可以使用 rewrites 從 Firebase Hosting 網址提供函式。以下範例節錄自使用 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)
    }
  } ]
}

region 在 function 區塊中的運作方式

如果 region 從 hosting.rewrites 設定的 function 區塊中省略，Firebase CLI 會嘗試自動偵測函式原始碼中的區域，如果未指定，則預設為 us-central1。如果無法取得函式的原始碼，CLI 會嘗試從已部署的函式偵測區域。如果函式位於多個區域，則 CLI 會要求在 hosting.rewrites 設定中指定 region。

pinTag 在 function 區塊中的運作方式

pinTag 功能僅適用於 Cloud Functions for Firebase (第 2 代)。有了這項功能，您就能確保用於產生網站動態內容的每個函式，都與靜態 Hosting 資源和 Hosting 設定保持同步。此外，這項功能還可讓您預覽 Hosting 預覽管道中的函式重寫內容。

如果您將 "pinTag": true 新增至 hosting.rewrites 設定檔的 function 區塊，則系統會在執行 firebase deploy --only hosting 時，將「已固定」函式與靜態 Hosting 資源和設定檔一併部署。如果您回溯網站的版本，則「固定」功能也會回溯。

注意： 如果您在現有重寫項目中新增 pinTag，必須先將更新後的重寫項目部署至「live」頻道。部署完成後，您就可以在 Hosting 預覽管道中預覽函式程式碼的變更，而不會影響實際執行環境。

這項功能需要使用 Cloud Run 標記，每項服務最多可使用 1000 個標記，每個區域最多可使用 2000 個標記。也就是說，在部署數百次後，網站最舊的版本可能會停止運作。

新增這項重寫規則並部署至 Firebase (使用 firebase deploy) 後，您就可以透過下列網址存取函式：

• 您的 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 網址存取 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)
   }
 } ]
}

pinTag 在 run 區塊中的運作方式

有了這項功能，您就能確保用於產生網站動態內容的 Cloud Run 服務修訂版本，與靜態 Hosting 資源和 Hosting 設定保持同步。此外，這項功能還可讓您在 Hosting 預覽管道中預覽重寫作業的 Cloud Run。

如果您將 "pinTag": true 新增至 hosting.rewrites 設定的 run 區塊，靜態 Hosting 資源和設定會在部署時，鎖定至 Cloud Run 服務的最新修訂版本。如果您回溯網站的版本，則「固定」Cloud Run 服務的修訂版本也會回溯。

這項功能需要使用 Cloud Run 標記，每項服務最多可使用 1000 個標記，每個區域最多可使用 2000 個標記。也就是說，在部署數百次後，網站最舊的版本可能會停止運作。

新增這項重寫規則並部署至 Firebase (使用 firebase deploy) 後，您可以透過下列網址存取容器映像檔：

• 您的 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 的路徑 與將路徑重寫為網址的規則不同，Dynamic Links 的重寫規則不得包含規則運算式。
	dynamicLinks	必須設為 true

重要事項：針對 Dynamic Links，請特別留意代管優先順序。

• 請確認 Dynamic Links 網址前置字串不會與優先順序較高的代管設定發生衝突 (例如，代管的靜態內容一律優先於重寫)。
• 在每個 redirects 和 rewrites 屬性中，Hosting 會使用與要求路徑相符的網址模式，套用 first 規則定義的重新導向或重寫。因此，您必須有意地為每個 redirects 和 rewrites 屬性中的規則排序。

詳情請參閱 Dynamic Links 說明文件。

設定標頭

選用
標頭可讓用戶端和伺服器在傳送要求或回應時，一併傳遞其他資訊。部分標頭組合可能會影響瀏覽器處理網頁及其內容的方式，包括存取控制、驗證、快取和編碼。

如要指定自訂的檔案專屬回應標頭，請建立包含標頭物件陣列的 headers 屬性。在每個物件中指定網址模式，如果與要求網址路徑相符，就會觸發 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 (建議) or regex		網址模式，如果與初始要求網址相符，就會觸發 Hosting 套用自訂標頭 使用 source 指定 glob(建議做法)。 使用 regex 指定 RE2 規則運算式。 如要建立可與自訂 404 網頁相符的標頭，請使用 404.html 做為 source 或 regex 值。
	(子)headers 的陣列		Hosting 套用至要求路徑的自訂標頭 每個副標題都必須包含 key 和 value 組合 (請參閱接下來兩個資料列)。
		key	標頭名稱，例如 Cache-Control
		value	標頭的值，例如 max-age=7200

注意： 系統會在應用任何重寫規則之前，先進行自訂標頭的網址模式比對。

如要進一步瞭解 Cache-Control，請參閱說明動態內容服務和代管微服務的 Hosting 部分。您也可以進一步瞭解 CORS 標頭。

重要事項： Firebase Hosting 會在預設 Hosting 子網域 (例如 *.web.app) 上覆寫 Strict-Transport-Security 設定。不過，任何已連結的自訂網域都會提供設定的值。

控制 .html 擴充功能

選用
cleanUrls 屬性可讓您控制網址是否應包含 .html 擴充功能。

在 true 時，Hosting 會自動從上傳檔案網址中移除 .html 擴充功能。如果在要求中新增 .html 擴充功能，Hosting 會執行 301 重新導向至相同路徑，但會移除 .html 擴充功能。

以下說明如何透過加入 cleanUrls 屬性，控管網址中是否要加入 .html：

"hosting": {
  // ...

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

控制尾部斜線

選用
trailingSlash 屬性可讓您控制靜態內容網址是否應包含尾端斜線。

• 當 true 時，Hosting 會將網址重新導向，並加上尾部斜線。
• 當 false 時，Hosting 會重新導向網址，移除結尾斜線。
• 如果未指定，Hosting 只會在目錄索引檔案 (例如 about/index.html) 中使用尾部斜線。

以下說明如何透過新增 trailingSlash 屬性來控制尾部斜線：

"hosting": {
  // ...

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

trailingSlash 屬性不會影響由 Cloud Functions 或 Cloud Run 提供的動態內容重寫作業。

Glob 模式比對

Firebase Hosting 設定選項會大量使用glob 模式比對符號與 extglob，類似於 Git 處理 gitignore 規則，以及 Bower 處理 ignore 規則的方式。這個 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",

  }
}