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

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

Skonfiguruj zachowanie Hostingu

Dzięki Firebase Hosting możesz skonfigurować niestandardowe zachowanie hostingu w przypadku żądań wysyłanych do Twojej witryny.

Co możesz skonfigurować w przypadku Hosting?

Określ, które pliki w lokalnym katalogu projektu chcesz wdrożyć na serwerFirebase Hosting. Więcej informacji
wyświetlać niestandardową stronę 404/Nie znaleziono; Więcej informacji
Skonfiguruj redirects dla przeniesionych lub usuniętych stron. Więcej informacji
Skonfiguruj rewrites na potrzeby:
- Wyświetlanie tej samej treści pod wieloma adresami URL. Dowiedz się, jak to zrobić
- Wykonywanie funkcji lub uzyskiwanie dostępu do kontenera Cloud Run z poziomu adresu URL Hosting. Dowiedz się, jak: funkcja lub kontener.
- Utwórz niestandardową domenę Dynamic Link. Dowiedz się, jak to zrobić
Dodaj headers, aby przekazać dodatkowe informacje o żądaniu lub odpowiedzi, np. o tym, jak przeglądarki powinny obsługiwać stronę i jej zawartość (uwierzytelnianie, buforowanie, kodowanie itp.). Dowiedz się, jak to zrobić
Skonfiguruj przekształcanie treści na potrzeby internacjonalizacji (i18n), aby wyświetlać określone treści na podstawie preferowanego języka lub kraju użytkownika. Dowiedz się, jak to zrobić (inna strona).

Gdzie definiujesz konfigurację Hosting?

Konfigurację Firebase Hosting określasz w pliku firebase.json. Gdy uruchomisz polecenie firebase init, Firebase automatycznie utworzy plik firebase.json w katalogu głównym katalogu projektu.

Poniżej znajdziesz przykład pełnej konfiguracji firebase.json (dotyczącej tylko Firebase Hosting). Pamiętaj, że plik firebase.json może też zawierać konfiguracje innych usług Firebase.

Za pomocą interfejsu Hosting API REST możesz sprawdzić wdrożony kontent firebase.json.

Priorytet odpowiedzi na Hosting

Różne opcje konfiguracji Firebase Hosting opisane na tej stronie mogą się czasami pokrywać. Jeśli wystąpi konflikt, Hosting określa odpowiedź zgodnie z tym priorytetem:

Zarezerwowane przestrzenie nazw, które zaczynają się od segmentu ścieżki /__/*
Skonfigurowane przekierowania
Treści statyczne z dopasowaniem ścisłym
Skonfigurowane przekierowania
Niestandardowa strona 404
Domyślna strona 404

Jeśli korzystasz z przepisów i18n, zakres dopasowania ścisłego i priorytetu obsługi 404 zostanie rozszerzony, aby uwzględnić Twoje „treści i18n”.

Określ pliki 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 do projektu 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, do którego katalogu ma zostać wdrożony element Firebase Hosting. Wartość domyślna to katalog o nazwie public, ale możesz określić ścieżkę dowolnego katalogu, o ile istnieje on w katalogu projektu.

Oto domyślna nazwa katalogu, który chcesz wdrożyć:

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

  // ...
}

Możesz zmienić domyślną wartość na katalog, który chcesz wdrożyć:

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

  // ...
}

ignorować

Opcjonalny
Atrybut ignore określa pliki, które mają być ignorowane podczas wdrażania. Może ona obsługiwać globy w taki sam sposób, w jaki Git obsługuje .gitignore.

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świetlić niestandardowy błąd 404 Not Found, gdy użytkownik spróbuje uzyskać dostęp do nieistniejącej strony.

Utwórz nowy plik w katalogu public projektu, nadaj mu nazwę 404.html, a potem dodaj do niego niestandardową zawartość 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 niedziałającym linkom w przypadku przeniesienia strony lub skrócenia adresów 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 przekierowań”). W każdym regułach określ wzór adresu URL, który po dopasowaniu do ścieżki adresu URL żądania powoduje, że reguła Hosting odpowiada przekierowaniem do określonego adresu URL docelowego.

Oto podstawowa struktura atrybutu redirects. W tym przykładzie żądania do /foo są przekierowywane przez wysłanie nowego żądania 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, przy czym każda reguła musi zawierać pola z poniższej tabeli.

Na początku każdego żądania Firebase Hosting porównuje wartość source lub regex ze wszystkimi ścieżkami adresu URL (zanim przeglądarka sprawdzi, czy w danej ścieżce znajduje się plik lub folder). Jeśli zostanie znalezione dopasowanie, serwer źródłowy Firebase Hosting wysyła odpowiedź z przekierowaniem HTTPS, informując 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 zastosowanie przekierowania.Hosting Użyj wartości `source`, aby określić glob (zalecane). Użyj `regex`, aby określić wyrażenie regularne RE2.
	`destination`	Statyczny adres URL, do którego przeglądarka powinna wysłać nowe żądanie Ten adres URL może być ścieżką względną lub bezwzględną.
	`type`	Kod odpowiedzi HTTPS W przypadku wartości „Przeniesiono na stałe” użyj typu `301`. Jako „znaleziono” (tymczasowe przekierowanie) użyj typu `302`

Przechwytywanie segmentów adresów URL w przypadku przekierowań

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

Rejestrowanie segmentów adresów URL podczas korzystania z symboli wieloznacznych

Jeśli używasz pola source (czyli podajesz w wzorze adresu URL wzór ogólny), możesz rejestrować segmenty, dodając prefiks :, aby je identyfikować. Jeśli chcesz też przechwycić pozostałą ścieżkę adresu URL po segmencie, umieść * 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
  } ]
}

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

Jeśli używasz pola regex (czyli podajesz wyrażenie regularne RE2 dla wzorca adresu URL), możesz rejestrować segmenty za pomocą nazwanych lub nienazwanych grup RE2. Nazwanych grup przechwytywania można używać w polu destination z prefiksem :, a nienazwane grupy przechwytywania mogą być wywoływane przez ich indeks numeryczny w wartości regex zindeksowanej 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 przekierowań

Opcjonalnie
Użyj przepisywania, aby wyświetlać tę samą treść pod wieloma adresami URL. Modyfikacje są szczególnie przydatne w przypadku dopasowywania do wzorca, ponieważ możesz zaakceptować dowolny adres URL pasujący do wzorca, a kod po stronie klienta decyduje, co ma się wyświetlać.

Możesz też używać przekierowań do obsługi aplikacji, które do nawigacji korzystają z pushState HTML5. Gdy przeglądarka spróbuje otworzyć ścieżkę adresu URL pasującą do wzorca adresu source lub regex, zamiast tego otrzyma zawartość pliku pod adresem destination.

Określ przekierowania adresów URL, tworząc atrybut rewrites, który zawiera tablicę obiektów (nazywanych „regułami przekierowania”). W każdym regułach określ wzór adresu URL, który po dopasowaniu do ścieżki adresu URL żądania powoduje, że Hosting reaguje tak, jakby usługa otrzymała określony adres URL docelowy.

Oto podstawowa struktura atrybutu rewrites. W tym przykładzie serwer wysyła odpowiedźindex.html w przypadku żądań dotyczących 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ł przepisywania, z których każda reguła musi zawierać pola z poniższej tabeli.

Firebase Hosting stosuje regułę przepisywania tylko wtedy, gdy plik lub katalog nie istnieje pod ścieżką adresu URL pasującą do określonego wzorca adresu URL source lub regex. Gdy żądanie uruchamia regułę przekształcania, przeglądarka zwraca rzeczywistą zawartość pliku destination, a nie przekierowanie HTTP.

Pole Opis

Pole	Opis
`rewrites`
	`source` (zalecane) lub `regex`	Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje zastosowanie przekierowaniaHosting Użyj wartości `source`, aby określić glob (zalecane). Aby określić wyrażenie regularne RE2, użyj `regex`.
	`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 zastosowanie przekierowaniaHosting

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

destination

Plik lokalny, który musi istnieć.

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

Przekierowywanie żądań do funkcji

Możesz użyć funkcji rewrites, aby wywołać funkcję z adresu URL Firebase Hosting. Poniższy przykład to fragment wyświetlania treści dynamicznych za pomocą Cloud Functions.

Aby np. 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 funkcja region działa w bloku function

Jeśli funkcja region zostanie pominięta w bloku function konfiguracji hosting.rewrites, interfejs wiersza poleceń Firebase spróbuje automatycznie wykryć region na podstawie kodu źródłowego funkcji. Jeśli nie określono inaczej, domyślna wartość to us-central1. Jeśli kod źródłowy funkcji jest niedostępny, interfejs wiersza poleceń próbuje wykryć region na podstawie wdrożonej funkcji. Jeśli funkcja jest w wielu regionach, interfejs wiersza poleceń wymaga określenia region w konfiguracji hosting.rewrites.

Jak działa blok pinTag w ramach bloku function

Funkcja pinTag jest dostępna tylko w Cloud Functions for Firebase (2 generacji). Dzięki tej funkcji masz pewność, że każda funkcja generująca dynamiczną zawartość witryny jest synchronizowana z zasobami statycznymi Hosting i konfiguracją Hosting. Ta funkcja umożliwia również wyświetlenie podglądu przepisanych zmian na funkcje na Hosting kanałach podglądu.

Jeśli dodasz "pinTag": true do bloku function w konfiguracji hosting.rewrites, „przypięta” funkcja zostanie wdrożona wraz ze statyczną konfiguracją i zasobami Hosting, nawet gdy jest uruchomiona 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 przeredagowania, musisz najpierw wdrożyć zaktualizowane przeredagowanie na „aktywny” kanał. Po wdrożeniu możesz wyświetlić podgląd zmian w kodzie funkcji w Hosting kanałach podglądu, nie wpływając na produkcję.

Ta funkcja korzysta z tagów Cloud Run, 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 jej w Firebase (przy użyciu 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
dowolne połączone domeny niestandardowe:
CUSTOM_DOMAIN/bigben

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

Żądania kierowane bezpośrednio do kontenera Cloud Run

Za pomocą rewrites możesz uzyskać dostęp do kontenera Cloud Run z poziomu adresu URL Firebase Hosting. Poniższy przykład to fragment wyświetlania treści dynamicznych za pomocą Cloud Run.

Aby na przykład kierować wszystkie żądania ze strony /helloworld w witrynie Hosting do uruchamiania i uruchamiania 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 funkcja pinTag działa w bloku run

Dzięki tej funkcji masz pewność, że wersja usługi Cloud Run służąca do generowania dynamicznych treści witryny jest synchronizowana z zasobami statycznymi Hosting i konfiguracją Hosting. Ta funkcja umożliwia też wyświetlanie wersji przeredagowanych treści w Cloud Run na kanałach podglądu Hosting.

Jeśli dodasz "pinTag": true do bloku run konfiguracji hosting.rewrites, statyczne zasoby i konfiguracja Hosting zostaną przypięte do najnowszej wersji usługi Cloud Run w momencie wdrażania. Jeśli cofniesz wersję witryny, zostanie też wycofana wersja usługi „zablokowana”Cloud Run.

Ta funkcja korzysta z tagów Cloud Run, 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 na Firebase (za pomocą firebase deploy) obraz kontenera będzie dostępny pod następującymi adresami URL:

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

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

Aby uzyskać najlepszą wydajność, umieść usługę Cloud Run w usługach Hosting w tych regionach:

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

Przekierowania z formatu Hosting na format 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

Utwórz domenę niestandardową Dynamic Links

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

Używaj domeny niestandardowej tylko do obsługi 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 prefiksy ścieżek domen niestandardowych, których chcesz używać 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
  } ]
}

Aby skonfigurować Dynamic Links w pliku firebase.json, musisz wykonać te czynności:

Pole		Opis
`appAssociation`		Trzeba ustawić wartość `AUTO` Jeśli nie uwzględnisz tego atrybutu w konfiguracji, domyślnie `appAssociation` będzie równe `AUTO`. Gdy ten atrybut jest ustawiony na `AUTO`, usługa Hosting może dynamicznie generować pliki `assetlinks.json` i `apple-app-site-association` na żądanie.
`rewrites`
	`source`	Ścieżka, której chcesz użyć w przypadku Dynamic Links W przeciwieństwie do reguł, które przepisują ścieżki na adresy URL, reguły przepisywania dla Dynamic Links nie mogą zawierać wyrażeń regularnych.
	`dynamicLinks`	Trzeba ustawić wartość `true`

Skonfiguruj nagłówki

Opcjonalne
Nagłówki pozwalają klientowi i serwerowi przekazać dodatkowe informacje wraz z żądaniem lub odpowiedzią. Niektóre zestawy nagłówków mogą wpływać na sposób obsługi strony i jej zawartości przez przeglądarkę, w tym na kontrolę dostępu, uwierzytelnianie, przechowywanie w pamięci podręcznej i kodowanie.

Określ niestandardowe nagłówki odpowiedzi dotyczące konkretnego pliku, tworząc atrybut headers, który zawiera tablicę obiektów nagłówka. W każdym obiekcie podaj wzór adresu URL, który po dopasowaniu do ścieżki adresu URL żądania powoduje, że Hosting stosuje określone nagłówki odpowiedzi niestandardowej.

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 podane w tabeli poniżej.

Pole			Opis
`headers`
	`source` (zalecane) lub `regex`		Wzorzec adresu URL, który po dopasowaniu do początkowego adresu URL żądania powoduje Hosting zastosowanie nagłówka niestandardowego Użyj wartości `source`, aby określić glob (zalecane). Aby określić wyrażenie regularne RE2, użyj `regex`. Aby utworzyć nagłówek dopasowujący się do niestandardowej strony 404, użyj wartości `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 następne 2 wiersze).
		`key`	Nazwa nagłówka, np. `Cache-Control`
		`value`	Wartość nagłówka, np. `max-age=7200`

Więcej informacji o usłudze Cache-Control znajdziesz w sekcji Hosting dotyczącej udostępniania treści dynamicznych i hostowania mikroserwisów. Możesz też dowiedzieć się więcej o nagłówkach CORS.

Zarządzanie rozszerzeniami: `.html`

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

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

Aby kontrolować uwzględnianie atrybutu .html w adresach URL, użyj atrybutu cleanUrls:

"hosting": {
  // ...

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

sterowanie ukośnikami na końcu,

Opcjonalny
Atrybut trailingSlash pozwala określić, czy adresy URL treści statycznych mają zawierać ukośniki.

Gdy true, Hosting przekierowuje adresy URL, aby dodać końcową ukośnicę.
Gdy false, Hosting przekierowuje adresy URL tak, aby usunąć na końcu ukośnik.
Jeśli nie jest określone, Hosting używa tylko ukośników końcowych w plikach indeksu katalogu (np. about/index.html).

Oto jak kontrolować ukośniki końcowe przez dodanie atrybutu trailingSlash:

"hosting": {
  // ...

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

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

Dopasowywanie do wzorca glob

Opcje konfiguracji Firebase Hosting wykorzystują w dużym stopniu notację dopasowania wzorców glob z extglob, podobnie jak w przypadku 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 public.
** – pasuje do dowolnego pliku lub folderu w dowolnym podkatalogu.
* – pasuje tylko do plików i folderów w katalogu głównym katalogu public.
**/.* – pasuje do każdego pliku zaczynającego się od . (zwykle ukryte pliki, na przykład w folderze .git) w dowolnym katalogu podrzędnym.
**/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) – dopasowuje się do dowolnego pliku w dowolnym podkatalogu, który kończy się dokładnie jednym z tych elementów: .jpg, .jpeg, .gif lub .png.

Przykładowa pełna konfiguracja Hosting

Poniżej znajdziesz przykład pełnej 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",

  }
}

Skonfiguruj zachowanie Hostingu

Co możesz skonfigurować w przypadku Hosting?

Gdzie definiujesz konfigurację Hosting?

Priorytet odpowiedzi na Hosting

Określ pliki do wdrożenia

publiczna

ignorować

Dostosowywanie strony 404/Nie znaleziono

Konfigurowanie przekierowań

Przechwytywanie segmentów adresów URL w przypadku przekierowań

Konfigurowanie przekierowań

Przekierowywanie żądań do funkcji

Żądania kierowane bezpośrednio do kontenera Cloud Run

Utwórz domenę niestandardową Dynamic Links

Skonfiguruj nagłówki

Zarządzanie rozszerzeniami: .html

sterowanie ukośnikami na końcu,

Dopasowywanie do wzorca glob

Przykładowa pełna konfiguracja Hosting

Zarządzanie rozszerzeniami: `.html`