如果您在构建服务器端渲染的 Angular 或 Next.js 应用，不妨试试我们新一代的 Firebase App Hosting，这是一款适用于现代 Web 框架的全栈解决方案。

Ta strona została przetłumaczona przez Cloud Translation API.

Skonfiguruj zachowanie Hostingu

Za pomocą Firebase Hosting możesz skonfigurować dostosowane działanie hostingu w przypadku żądań kierowanych do Twojej witryny.

Co można skonfigurować w przypadku Hosting?

Określ, które pliki z lokalnego katalogu projektu chcesz wdrożyć w Firebase Hosting. Dowiedz się, jak to zrobić
Wyświetlaj dostosowaną stronę 404/Nie znaleziono. Dowiedz się, jak to zrobić
Skonfiguruj redirects w przypadku stron, które zostały przeniesione lub usunięte. Dowiedz się, jak to zrobić
Skonfiguruj urządzenie rewrites w jednym z tych celów:
- Wyświetlanie tych samych treści pod wieloma adresami URL. Dowiedz się, jak to zrobić
- Udostępniać funkcję lub uzyskiwać dostęp do kontenera Cloud Run z poziomu adresu URL Hosting. Dowiedz się, jak to zrobić: funkcja lub kontener.
- Utwórz domenę niestandardowąDynamic Link. Dowiedz się, jak to zrobić
Dodaj headers, aby przekazać dodatkowe informacje o żądaniu lub odpowiedzi, np. jak przeglądarki powinny obsługiwać stronę i jej zawartość (uwierzytelnianie, buforowanie, kodowanie itp.). Dowiedz się, jak to zrobić
Skonfiguruj przekształcenia związane z internacjonalizacją (i18n), aby wyświetlać określone treści na podstawie ustawień języka lub kraju użytkownika. Więcej informacji (inna strona).

Gdzie definiujesz Hosting konfigurację?

Konfigurację Firebase Hosting definiujesz w pliku firebase.json. Firebase automatycznie tworzy plik firebase.json w katalogu głównym projektu po uruchomieniu polecenia firebase init.

Pełny przykład konfiguracji (obejmujący tylko Firebase Hosting) znajdziesz u dołu tej strony.firebase.json Pamiętaj, że plik może też zawierać konfiguracje innych usług Firebase.firebase.json

Wdrożoną treść firebase.json możesz sprawdzić za pomocą Hosting interfejsu API REST.

Kolejność priorytetów odpowiedzi Hosting

Różne opcje konfiguracji Firebase Hosting opisane na tej stronie mogą się czasami pokrywać. W przypadku konfliktu Hosting określa odpowiedź zgodnie z tą kolejnością priorytetów:

Zarezerwowane przestrzenie nazw, które zaczynają się od segmentu ścieżki /__/*
Skonfigurowane przekierowania
Treści statyczne dopasowane dokładnie
Skonfigurowane zmiany
Niestandardowa strona 404
Domyślna strona 404

Jeśli używasz przekształceń i18n, zakres priorytetu dopasowania ścisłego i obsługi błędów 404 jest rozszerzany, aby uwzględnić „treści i18n”.

Określanie plików do wdrożenia

Domyślne atrybuty – public i ignore – zawarte w domyślnym pliku firebase.json określają, które pliki w katalogu projektu powinny zostać wdrożone w projekcie Firebase.

Domyślna konfiguracja hosting w pliku firebase.json wygląda tak:

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

publiczna

Wymagany
Atrybut public określa katalog, w którym ma zostać wdrożona aplikacjaFirebase Hosting. Wartość domyślna to katalog o nazwie public, ale możesz podać ścieżkę dowolnego katalogu, o ile znajduje się on w katalogu projektu.

Domyślna nazwa katalogu do wdrożenia to:

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

  // ...
}

Możesz zmienić wartość domyślną na katalog, w którym chcesz wdrożyć aplikację:

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

  // ...
}

ignoruj

Opcjonalnie
Atrybut ignore określa pliki, które mają być ignorowane podczas wdrażania. Może przyjmować wzorce w taki sam sposób jak Git obsługuje .gitignore.

Oto domyślne wartości plików do zignorowania:

"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
  ]
}

Dostosowywanie strony 404/Nie znaleziono

Opcjonalnie
Możesz wyświetlać niestandardowy 404 Not Found błąd, gdy użytkownik próbuje uzyskać dostęp do strony, która nie istnieje.

Utwórz nowy plik w katalogu public projektu, nadaj mu nazwę 404.html, a następnie dodaj do niego niestandardową treść 404 Not Found.

Firebase Hosting wyświetli zawartość tej niestandardowej strony 404.html, jeśli przeglądarka wywoła błąd 404 Not Found w Twojej domenie lub subdomenie.

Konfigurowanie przekierowań

Opcjonalnie
Użyj przekierowania adresu URL, aby zapobiec powstawaniu uszkodzonych linków, jeśli strona została przeniesiona, lub aby skrócić adresy URL. Możesz na przykład przekierować przeglądarkę z example.com/team na example.com/about.html.

Określ przekierowania adresów URL, tworząc atrybut redirects, który zawiera tablicę obiektów (nazywanych „regułami przekierowania”). W każdej regule określ wzorzec adresu URL, który, jeśli zostanie dopasowany do ścieżki adresu URL żądania, spowoduje, że Hosting odpowie przekierowaniem na określony docelowy adres URL.

Oto podstawowa struktura atrybutu redirects. Ten przykład przekierowuje żądania do /foo, wysyłając nowe żądanie do /bar.

"hosting": {
  // ...

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

Zobacz bardziej szczegółowy przykład atrybutu 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
  } ]
}

Atrybut redirects zawiera tablicę reguł przekierowania, z których każda musi zawierać pola z tabeli poniżej.

Firebase Hosting porównuje wartość source lub regex ze wszystkimi ścieżkami URL na początku każdego żądania (zanim przeglądarka określi, czy w danej ścieżce znajduje się plik lub folder). Jeśli zostanie znalezione dopasowanie, serwer pierwotny Firebase Hosting wysyła odpowiedź przekierowującą HTTPS, która informuje przeglądarkę, że ma wysłać nowe żądanie pod adresem URL destination.

Pole		Opis
`redirects`
	`source` (zalecane) lub `regex`	Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje, że Hosting stosuje przekierowanie. Użyj `source`, aby określić glob (zalecane). Użyj znaku `regex`, aby określić wyrażenie regularne RE2.
	`destination`	Statyczny adres URL, pod który przeglądarka powinna wysłać nowe żądanie. Może to być ścieżka względna lub bezwzględna.
	`type`	Kod odpowiedzi HTTPS W przypadku „Przeniesiono na stałe” użyj typu `301`. Używaj typu `302` w przypadku „Znaleziono” (przekierowanie tymczasowe).

Przechwytywanie segmentów adresu URL na potrzeby przekierowań

Opcjonalnie
Czasami może być konieczne przechwycenie określonych segmentów adresu URL reguły przekierowania (wartość source lub regex), a następnie ponowne użycie tych segmentów w ścieżce destination reguły.

Przechwytywanie segmentów adresu URL podczas używania symboli wieloznacznych

Jeśli używasz pola source (czyli określasz wzorzec adresu URL za pomocą symbolu wieloznacznego), możesz przechwytywać segmenty, dodając prefiks :, aby je identyfikować. Jeśli chcesz też przechwycić pozostałą część ścieżki adresu URL po segmencie, umieść znak * bezpośrednio po segmencie. Przykład:

"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
  } ]
}

Przechwytywanie segmentów adresu URL podczas korzystania z wyrażeń regularnych RE2

Jeśli używasz pola regex (czyli określasz wyrażenie regularne RE2 dla wzorca adresu URL), możesz rejestrować segmenty za pomocą nazwanych lub nienazwanych grup przechwytywania RE2. Nazwane grupy przechwytywania można stosować w polu destination z prefiksem :, a do nienazwanych grup przechwytywania można się odwoływać za pomocą indeksu liczbowego w wartości regex, indeksowanego od 1. Przykład:

"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
  } ]
}

Konfigurowanie przepisania

Opcjonalnie
Użyj przekierowania, aby wyświetlać te same treści w przypadku wielu adresów URL. Przekierowania są szczególnie przydatne w przypadku dopasowywania wzorców, ponieważ możesz akceptować dowolny adres URL pasujący do wzorca i pozwolić kodowi po stronie klienta decydować o tym, co ma być wyświetlane.

Możesz też używać przepisów, aby obsługiwać aplikacje, które do nawigacji wykorzystują HTML5 pushState. Gdy przeglądarka spróbuje otworzyć ścieżkę adresu URL, która pasuje do określonego wzorca adresu URL source lub regex, zamiast tego otrzyma zawartość pliku pod adresem URL destination.

Określ przekształcenia adresów URL, tworząc atrybut rewrites, który zawiera tablicę obiektów (nazywanych „regułami przekształcania”). W każdej regule określ wzorzec adresu URL, który, jeśli zostanie dopasowany do ścieżki adresu URL żądania, spowoduje, że Hosting odpowie tak, jakby usługa otrzymała określony docelowy adres URL.

Oto podstawowa struktura atrybutu rewrites. Ten przykład obsługuje index.html żądania plików lub katalogów, które nie istnieją.

"hosting": {
  // ...

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

Zobacz bardziej szczegółowy przykład atrybutu 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"
} ]
}

Atrybut rewrites zawiera tablicę reguł ponownego zapisu, z których każda musi zawierać pola z tabeli poniżej.

Firebase Hosting stosuje regułę przekształcania tylko wtedy, gdy w ścieżce URL pasującej do określonego wzorca URL source lub regex nie ma pliku ani katalogu. Gdy żądanie uruchomi regułę przepisywania, przeglądarka zwróci rzeczywistą zawartość określonego pliku destination zamiast przekierowania HTTP.

Pole Opis

Pole	Opis
`rewrites`
	`source` (zalecane) lub `regex`	Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje, że Hosting stosuje przepisanie. Użyj `source`, aby określić glob (zalecane). Użyj znaku `regex`, aby określić wyrażenie regularne RE2.
	`destination`	plik lokalny, który musi istnieć; Może to być ścieżka względna lub bezwzględna.

rewrites

source (zalecane)
lub regex

Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje, że Hosting stosuje przepisanie.

Użyj source, aby określić glob (zalecane).
Użyj znaku regex, aby określić wyrażenie regularne RE2.

destination

plik lokalny, który musi istnieć;

Może to być ścieżka względna lub bezwzględna.

Bezpośrednie prośby do funkcji

Możesz użyć usługi rewrites, aby udostępnić funkcję z adresu URL Firebase Hosting. Poniższy przykład to fragment artykułu Wyświetlanie treści dynamicznych za pomocą Cloud Functions.

Aby na przykład skierować wszystkie żądania ze strony /bigben w witrynie Hosting do wykonania funkcji 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)
    }
  } ]
}

Jak działa region w bloku function

Jeśli w bloku function konfiguracji hosting.rewrites pominięto region, interfejs Firebase CLI próbuje automatycznie wykryć region na podstawie kodu źródłowego funkcji, który, jeśli nie zostanie określony, domyślnie przyjmuje wartość us-central1. Jeśli kod źródłowy funkcji jest niedostępny, interfejs CLI próbuje wykryć region na podstawie wdrożonej funkcji. Jeśli funkcja znajduje się w kilku regionach, interfejs CLI wymaga podania region w hosting.rewrites konfiguracji.

Jak działa pinTag w bloku function

Funkcja pinTag jest dostępna tylko w przypadku Cloud Functions for Firebase (2 generacji). Dzięki tej funkcji możesz mieć pewność, że każda funkcja generująca treści dynamiczne witryny jest zsynchronizowana ze statycznymi zasobami Hosting i konfiguracją Hosting. Ta funkcja umożliwia też wyświetlanie podglądu przepisanych funkcji na Hosting kanałach podglądu.

Jeśli dodasz "pinTag": true do bloku function w konfiguracji hosting.rewrites, funkcja „przypięta” zostanie wdrożona wraz z zasobami statycznymi Hosting i konfiguracją, nawet podczas uruchamiania firebase deploy --only hosting. Jeśli cofniesz wersję witryny, funkcja „przypięcia” również zostanie cofnięta.

Uwaga: jeśli dodasz pinTag do istniejącego przepisywania, musisz najpierw wdrożyć zaktualizowane przepisywanie na kanale „na żywo”. Po wdrożeniu możesz wyświetlić podgląd zmian w kodzie funkcji w Hostingkanałach podglądu bez wpływu na wersję produkcyjną.

Ta funkcja korzysta z Cloud Runtagów, których limit wynosi 1000 tagów na usługę i 2000 tagów na region. Oznacza to, że po setkach wdrożeń najstarsze wersje witryny mogą przestać działać.

Po dodaniu tej reguły przepisywania i wdrożeniu w Firebase (za pomocą firebase deploy) funkcja będzie dostępna pod tymi adresami URL:

Twoje subdomeny Firebase:
PROJECT_ID.web.app/bigben i PROJECT_ID.firebaseapp.com/bigben
Wszystkie połączone domeny niestandardowe:
CUSTOM_DOMAIN/bigben

Gdy Firebase Hosting przekazuje ruch do funkcji, otrzymuje ona pełną ścieżkę oryginalnego żądania i ciąg zapytania. Na przykład żądanie /bigben/hello/world?foo=bar w witrynie Hosting jest przekazywane do funkcji z zachowaniem pełnej ścieżki i zapytania. Upewnij się, że funkcja obsługi jest napisana tak, aby obsługiwać cały bezwzględny adres URL, a nie tylko ścieżkę podstawową zdefiniowaną w przepisywaniu.

Podczas przekierowywania żądań do funkcji z Hosting obsługiwane metody żądań HTTP to GET, POST, HEAD, PUT, DELETE, PATCH i OPTIONS. Inne metody, takie jak REPORT czy PROFIND, nie są obsługiwane.

Bezpośrednie żądania do kontenera Cloud Run

Możesz użyć rewrites, aby uzyskać dostęp do kontenera Cloud Run z adresu URL Firebase Hosting. Poniższy przykład to fragment artykułu wyświetlanie treści dynamicznych za pomocą Cloud Run.

Aby na przykład skierować wszystkie żądania ze strony /helloworld w Twojej witrynie Hosting do uruchomienia i działania instancji kontenera 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)
   }
 } ]
}

Jak działa pinTag w bloku run

Dzięki tej funkcji możesz mieć pewność, że wersja Cloud Runusługi generującej dynamiczne treści witryny jest zsynchronizowana ze statycznymi zasobami Hosting i konfiguracją Hosting. Ta funkcja umożliwia też wyświetlanie podglądu zmian w Cloud Run na kanałach podglądu Hosting.

Jeśli dodasz "pinTag": true do bloku run w hosting.rewriteskonfiguracji, Twoje statyczne zasoby Hosting i konfiguracja zostaną przypięte do najnowszej wersji usługi Cloud Run w momencie wdrożenia. Jeśli cofniesz wersję witryny, cofnięta zostanie też wersja „przypiętej”Cloud Run usługi.

Ta funkcja korzysta z Cloud Runtagów, których limit wynosi 1000 tagów na usługę i 2000 tagów na region. Oznacza to, że po setkach wdrożeń najstarsze wersje witryny mogą przestać działać.

Po dodaniu tej reguły przekierowania i wdrożeniu w Firebase (za pomocą firebase deploy) obraz kontenera będzie dostępny pod tymi adresami URL:

Twoje subdomeny Firebase:
PROJECT_ID.web.app/helloworld i PROJECT_ID.firebaseapp.com/helloworld
Wszystkie połączone domeny niestandardowe:
CUSTOM_DOMAIN/helloworld

Podczas przekierowywania żądań do kontenerów Cloud Run z Hosting obsługiwane metody żądań HTTP to GET, POST, HEAD, PUT, DELETE, PATCH i OPTIONS. Inne metody, takie jak REPORT czy PROFIND, nie są obsługiwane.

Aby uzyskać optymalną wydajność, umieść usługę Cloud Run w tej samej lokalizacji co Hosting w tych regionach:

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

Przekształcenia z Hosting na Cloud Run są obsługiwane w tych regionach:

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

Tworzenie domeny niestandardowejDynamic Links

Możesz użyć rewrites, aby utworzyć domenę niestandardową Dynamic Links. Szczegółowe informacje o konfigurowaniu domeny niestandardowej dla Dynamic Links znajdziesz w dokumentacjiDynamic Links.

Używaj domeny niestandardowej tylko w przypadku 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
  } ]
}

Określ niestandardowe prefiksy ścieżki domeny, które mają być używane w przypadku 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
  } ]
}

Konfigurowanie Dynamic Links w pliku firebase.json wymaga:

Pole		Opis
`appAssociation`		Musi mieć wartość `AUTO` Jeśli nie uwzględnisz tego atrybutu w konfiguracji, domyślna wartość `appAssociation` to `AUTO`. Ustawiając ten atrybut na `AUTO`, Hosting może dynamicznie generować pliki `assetlinks.json` i `apple-app-site-association`, gdy są one wymagane.
`rewrites`
	`source`	ścieżkę, której chcesz użyć do działania Dynamic Links; W przeciwieństwie do reguł, które przepisują ścieżki na adresy URL, reguły przepisywania dla elementu Dynamic Links nie mogą zawierać wyrażeń regularnych.
	`dynamicLinks`	Musi mieć wartość `true`

Konfigurowanie nagłówków

Opcjonalne
Nagłówki umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji wraz z żądaniem lub odpowiedzią. Niektóre zestawy nagłówków mogą wpływać na sposób, w jaki przeglądarka obsługuje stronę i jej zawartość, w tym na kontrolę dostępu, uwierzytelnianie, buforowanie i kodowanie.

Określ niestandardowe nagłówki odpowiedzi dotyczące konkretnych plików, tworząc atrybut headers, który zawiera tablicę obiektów nagłówka. W każdym obiekcie określ wzorzec adresu URL, który w przypadku dopasowania do ścieżki adresu URL żądania spowoduje zastosowanie przez Hosting określonych niestandardowych nagłówków odpowiedzi.

Oto podstawowa struktura atrybutu headers. W tym przykładzie nagłówek CORS jest stosowany do wszystkich plików czcionek.

"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": "*"
    } ]
  } ]
}

Zobacz bardziej szczegółowy przykład atrybutu 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"
    } ]
  } ]
}

Atrybut headers zawiera tablicę definicji, z których każda musi zawierać pola z tabeli poniżej.

Pole			Opis
`headers`
	`source` (zalecane) lub `regex`		Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje, że Hosting stosuje niestandardowy nagłówek. Użyj `source`, aby określić glob (zalecane). Użyj znaku `regex`, aby określić wyrażenie regularne RE2. Aby utworzyć nagłówek pasujący do niestandardowej strony 404, użyj znaku `404.html` jako wartości `source` lub `regex`.
	tablica (pod)`headers`		niestandardowe nagłówki, które Hosting stosuje do ścieżki żądania; Każdy podnagłówek musi zawierać parę `key` i `value` (patrz 2 następne wiersze).
		`key`	Nazwa nagłówka, np. `Cache-Control`
		`value`	Wartość nagłówka, np. `max-age=7200`

Więcej informacji o Cache-Control znajdziesz w sekcji Hosting, która opisuje wyświetlanie treści dynamicznych i hostowanie mikrousług. Możesz też dowiedzieć się więcej o nagłówkach CORS.

Sterowanie rozszerzeniami `.html`

Opcjonalny
Atrybut cleanUrls pozwala określić, czy adresy URL mają zawierać rozszerzenie .html.

Gdy true, Hosting automatycznie usuwa rozszerzenie .html z przesłanych adresów URL plików. Jeśli w żądaniu zostanie dodane rozszerzenie .html, Hosting wykona przekierowanie 301 do tej samej ścieżki, ale bez rozszerzenia .html.

Aby kontrolować uwzględnianie znaku .html w adresach URL, dodaj atrybut cleanUrls:

"hosting": {
  // ...

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

Kontrolowanie ukośników na końcu adresu URL

Opcjonalny
Atrybut trailingSlash umożliwia określenie, czy adresy URL treści statycznych powinny zawierać ukośniki na końcu.

Gdy true, Hosting przekierowuje adresy URL, aby dodać ukośnik na końcu.
Gdy false, Hosting przekierowuje adresy URL, aby usunąć końcowy ukośnik.
Jeśli nie zostanie podana, usługa Hosting używa ukośników na końcu tylko w przypadku plików indeksu katalogu (np. about/index.html).

Aby kontrolować ukośniki na końcu, dodaj atrybut trailingSlash:

"hosting": {
  // ...

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

Atrybut trailingSlash nie ma wpływu na przepisywanie dynamicznych treści wyświetlanych przez Cloud Functions lub Cloud Run.

Dopasowywanie wzorców glob

Opcje konfiguracji Firebase Hosting w dużej mierze korzystają z notacji dopasowywania wzorców glob z extglob, podobnie jak Git obsługuje reguły gitignore, a Bower obsługuje reguły ignore. Ta strona wiki zawiera bardziej szczegółowe informacje, ale poniżej znajdziesz wyjaśnienia przykładów użytych na tej stronie:

firebase.json – pasuje tylko do pliku firebase.json w katalogu głównym katalogu public.
** – pasuje do dowolnego pliku lub folderu w dowolnym podkatalogu.
* – pasuje tylko do plików i folderów w katalogu głównym public.
**/.* – pasuje do każdego pliku zaczynającego się od . (zwykle ukryte pliki, np. w folderze .git) w dowolnym podkatalogu.
**/node_modules/** – pasuje do dowolnego pliku lub folderu w dowolnym podkatalogu folderu node_modules, który może znajdować się w dowolnym podkatalogu katalogu public.
**/*.@(jpg|jpeg|gif|png) – pasuje do dowolnego pliku w dowolnym podkatalogu, który kończy się dokładnie jednym z tych znaków: .jpg, .jpeg, .gif lub .png.

Pełny przykład konfiguracji Hosting

Poniżej znajdziesz pełny przykład konfiguracji firebase.json w przypadku Firebase Hosting. Pamiętaj, że plik firebase.json może też zawierać konfiguracje innych usług 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",

  }
}