Hosting-Verhalten konfigurieren

Mit Firebase Hosting können Sie ein benutzerdefiniertes Hosting-Verhalten für Anfragen an Ihre Website konfigurieren.

Was können Sie für Hosting konfigurieren?

• Geben Sie an, welche Dateien in Ihrem lokalen Projektverzeichnis Sie in Firebase Hosting bereitstellen möchten. Weitere Informationen

• Eine benutzerdefinierte 404-Seite (Seite nicht gefunden) anzeigen. Weitere Informationen

• Richten Sie redirects für Seiten ein, die Sie verschoben oder gelöscht haben. Weitere Informationen

• rewrites für einen der folgenden Zwecke einrichten:

  • Zeigen Sie dieselben Inhalte für mehrere URLs an. Weitere Informationen

  • Eine Funktion bereitstellen oder über eine Hosting-URL auf einen Cloud Run-Container zugreifen Weitere Informationen finden Sie unter Funktion oder Container.

  • Erstellen Sie eine benutzerdefinierte Domain Dynamic Link. Weitere Informationen

• Fügen Sie headers hinzu, um zusätzliche Informationen zu einer Anfrage oder Antwort zu übergeben, z. B. wie Browser mit der Seite und ihren Inhalten umgehen sollen (Authentifizierung, Caching, Codierung usw.). Weitere Informationen

• Richten Sie i18n-Umschreibungen ein, um bestimmte Inhalte basierend auf der Spracheinstellung und/oder dem Land eines Nutzers zu präsentieren. Weitere Informationen (andere Seite)

Wo definieren Sie Ihre Hosting-Konfiguration?

Sie definieren die Firebase Hosting-Konfiguration in der Datei firebase.json. Firebase erstellt die firebase.json-Datei automatisch im Stammverzeichnis Ihres Projektverzeichnisses, wenn Sie den Befehl firebase init ausführen.

Achtung :Wenn Sie firebase init noch einmal ausführen und Hosting auswählen, wird der Abschnitt hosting der Datei firebase.json mit der Standardkonfiguration überschrieben.

Unten auf dieser Seite findest du ein vollständiges firebase.json-Konfigurationsbeispiel, das nur Firebase Hosting abdeckt. Eine firebase.json-Datei kann auch Konfigurationen für andere Firebase-Dienste enthalten.

Sie können die bereitgestellten firebase.json-Inhalte mit der Hosting REST API prüfen.

Prioritätenreihenfolge der Hosting-Antworten

Die auf dieser Seite beschriebenen verschiedenen Firebase Hosting-Konfigurationsoptionen können sich manchmal überschneiden. Bei einem Konflikt bestimmt Hosting seine Antwort anhand der folgenden Prioritätsreihenfolge:

1. Reservierte Namespaces, die mit einem Pfadsegment /__/* beginnen
2. Konfigurierte Weiterleitungen
3. Statische Inhalte mit exakter Übereinstimmung
4. Konfigurierte Umschreibungen
5. Benutzerdefinierte 404-Seite
6. Standard-404-Seite

Wichtig :Innerhalb der Attribute redirects und rewrites wendet Hosting die Weiterleitung oder Umschreibung an, die durch die erste Regel mit einem URL-Muster definiert ist, das mit dem angeforderten Pfad übereinstimmt. Sie müssen die Regeln also in den einzelnen redirects- und rewrites-Attributen bewusst anordnen. Konfigurierte redirects haben weiterhin Vorrang vor rewrites.

Wenn Sie I18n-Weiterleitungen verwenden, wird die Prioritätsreihenfolge für die genaue Übereinstimmung und die 404-Behandlung erweitert, um Ihre „I18n-Inhalte“ zu berücksichtigen.

Angeben, welche Dateien bereitgestellt werden sollen

Die Standardattribute public und ignore in der Standarddatei firebase.json definieren, welche Dateien in Ihrem Projektverzeichnis in Ihrem Firebase-Projekt bereitgestellt werden sollen.

Die Standardhosting-Konfiguration in einer firebase.json-Datei sieht so aus:

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

Öffentlich

Erforderlich
Mit dem public-Attribut wird angegeben, in welchem Verzeichnis Firebase Hosting bereitgestellt werden soll. Der Standardwert ist ein Verzeichnis mit dem Namen public. Sie können jedoch den Pfad eines beliebigen Verzeichnisses angeben, sofern es sich im Projektverzeichnis befindet.

Im Folgenden finden Sie den standardmäßig angegebenen Namen des zu verschiebenden Verzeichnisses:

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

  // ...
}

Sie können den Standardwert in das Verzeichnis ändern, das Sie bereitstellen möchten:

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

  // ...
}

ignorieren

Optional
Mit dem ignore-Attribut werden die Dateien angegeben, die beim Bereitstellen ignoriert werden sollen. Es kann Glob-Strings auf dieselbe Weise verarbeiten wie Git .gitignore.

Die folgenden Standardwerte gelten für die zu ignorierenden Dateien:

"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-Seite (Seite nicht gefunden) anpassen

Optional
Sie können einen benutzerdefinierten 404 Not Found-Fehler ausgeben, wenn ein Nutzer versucht, auf eine Seite zuzugreifen, die nicht existiert.

Erstellen Sie im Verzeichnis public Ihres Projekts eine neue Datei mit dem Namen 404.html und fügen Sie der Datei Ihre benutzerdefinierten 404 Not Found-Inhalte hinzu.

Firebase Hosting zeigt den Inhalt dieser benutzerdefinierten 404.html-Seite an, wenn ein Browser einen 404 Not Found-Fehler in Ihrer Domain oder Subdomain auslöst.

Weiterleitungen konfigurieren

Optional
Mit einer URL-Weiterleitung können Sie verhindern, dass Links auf eine nicht mehr vorhandene Seite verweisen, wenn Sie eine Seite verschoben haben, oder URLs verkürzen. Sie können einen Browser beispielsweise von example.com/team zu example.com/about.html weiterleiten.

URL-Weiterleitungen können Sie angeben, indem Sie ein redirects-Attribut mit einem Array von Objekten (sogenannte „Weiterleitungsregeln“) erstellen. Geben Sie in jeder Regel ein URL-Muster an, das Hosting dazu veranlasst, bei Übereinstimmung mit dem URL-Pfad der Anfrage eine Weiterleitung zur angegebenen Ziel-URL zu senden.

Hier ist die grundlegende Struktur für ein redirects-Attribut. In diesem Beispiel werden Anfragen an /foo weitergeleitet, indem eine neue Anfrage an /bar gesendet wird.

"hosting": {
  // ...

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

Detailliertes Beispiel für ein redirects-Attribut

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

Das redirects-Attribut enthält ein Array mit Weiterleitungsregeln. Jede Regel muss die Felder in der folgenden Tabelle enthalten.

Firebase Hosting vergleicht den Wert source oder regex zu Beginn jeder Anfrage mit allen URL-Pfaden, bevor der Browser ermittelt, ob sich an diesem Pfad eine Datei oder ein Ordner befindet. Wenn eine Übereinstimmung gefunden wird, sendet der Firebase Hosting-Ursprungsserver eine HTTPS-Weiterleitungsantwort, in der der Browser aufgefordert wird, eine neue Anfrage an die destination-URL zu senden.

Feld		Beschreibung
redirects
	source (empfohlen) oder regex	Ein URL-Muster, das bei Übereinstimmung mit der URL der ursprünglichen Anfrage Hosting dazu veranlasst, die Weiterleitung anzuwenden Verwenden Sie source, um einen Globus (empfohlen) anzugeben. Verwenden Sie regex, um einen regulären RE2-Ausdruck anzugeben.
	destination	Eine statische URL, an die der Browser eine neue Anfrage senden soll Diese URL kann ein relativer oder absoluter Pfad sein.
	type	Der HTTPS-Antwortcode Verwenden Sie den Typ 301 für „Permanent verschoben“ Verwenden Sie den Typ 302 für „Gefunden“ (vorübergehende Weiterleitung).

Wichtig: Innerhalb des Attributs redirects wendet Hosting die Weiterleitung an, die durch die Regel first mit einem URL-Muster definiert ist, das mit dem angeforderten Pfad übereinstimmt. Daher müssen Sie die Regeln im redirects-Attribut bewusst anordnen.

URL-Segmente für Weiterleitungen erfassen

Optional
Manchmal müssen Sie bestimmte Segmente des URL-Musters (source- oder regex-Wert) einer Weiterleitungsregel erfassen und dann im destination-Pfad der Regel wiederverwenden.

URL-Segmente bei Verwendung von Globs erfassen

Wenn Sie ein source-Feld verwenden (d. h. ein Globus für Ihr URL-Muster angeben), können Sie Segmente erfassen, indem Sie ein :-Präfix zur Identifizierung des Segments angeben. Wenn Sie auch den verbleibenden URL-Pfad nach dem Segment erfassen möchten, fügen Sie direkt nach dem Segment ein * ein. Beispiel:

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

URL-Segmente bei Verwendung von regulären RE2-Ausdrücken erfassen

Wenn Sie ein regex-Feld verwenden, also einen RE2-regulären Ausdruck für Ihr URL-Muster angeben, können Sie Segmente mit benannten oder unbenannten RE2-Aufnahmegruppen erfassen. Benannte Erfassungsgruppen können im Feld destination mit dem Präfix : verwendet werden. Auf unbenannte Erfassungsgruppen kann im Wert regex durch ihren numerischen Index verwiesen werden, der mit 1 beginnt. Beispiel:

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

Umschreibungen konfigurieren

Optional
Mit einem Rewrite können Sie dieselben Inhalte für mehrere URLs anzeigen. Rewrites sind besonders nützlich bei Musterabgleich, da Sie jede URL akzeptieren können, die dem Muster entspricht, und den clientseitigen Code entscheiden lassen, was angezeigt werden soll.

Sie können Rewrites auch für Apps verwenden, die HTML5 pushState für die Navigation verwenden. Wenn ein Browser versucht, einen URL-Pfad zu öffnen, der mit dem angegebenen source- oder regex-URL-Muster übereinstimmt, wird dem Browser stattdessen der Inhalt der Datei an der destination-URL übergeben.

Geben Sie URL-Weiterleitungen an, indem Sie ein rewrites-Attribut mit einem Array von Objekten (sogenannte „Weiterleitungsregeln“) erstellen. Geben Sie in jeder Regel ein URL-Muster an, das Hosting dazu veranlasst, bei Übereinstimmung mit dem URL-Pfad der Anfrage so zu reagieren, als wäre dem Dienst die angegebene Ziel-URL übergeben worden.

Hier ist die grundlegende Struktur für ein rewrites-Attribut. In diesem Beispiel wird index.html für Anfragen an Dateien oder Verzeichnisse bereitgestellt, die nicht vorhanden sind.

"hosting": {
  // ...

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

Detailliertes Beispiel für ein rewrites-Attribut

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

Das rewrites-Attribut enthält ein Array von Umschreibregeln. Jede Regel muss die Felder in der folgenden Tabelle enthalten.

Firebase Hosting wendet eine Umschreibregel nur an, wenn eine Datei oder ein Verzeichnis nicht unter einem URL-Pfad vorhanden ist, der mit dem angegebenen source- oder regex-URL-Muster übereinstimmt. Wenn eine Anfrage eine Umschreiberegel auslöst, gibt der Browser den tatsächlichen Inhalt der angegebenen destination-Datei anstelle einer HTTP-Weiterleitung zurück.

Feld		Beschreibung
rewrites
	source (empfohlen) oder regex	Ein URL-Muster, das bei Übereinstimmung mit der ursprünglichen Anfrage-URL Hosting auslöst, um die Umschreibung anzuwenden Verwenden Sie source, um einen Globus (empfohlen) anzugeben. Verwenden Sie regex, um einen regulären RE2-Ausdruck anzugeben.
	destination	Eine lokale Datei, die vorhanden sein muss Diese URL kann ein relativer oder absoluter Pfad sein.

Wichtig :Innerhalb des Attributs rewrites wendet Hosting die Umwandlung an, die durch die erste Regel mit einem URL-Muster definiert ist, das mit dem angeforderten Pfad übereinstimmt. Daher müssen Sie die Regeln im rewrites-Attribut bewusst anordnen.

Anfragen direkt an eine Funktion senden

Mit rewrites können Sie eine Funktion über eine Firebase Hosting-URL bereitstellen. Das folgende Beispiel ist ein Auszug aus Dynamische Inhalte mit Cloud Functions ausliefern.

So leiten Sie beispielsweise alle Anfragen von der Seite /bigben auf Ihrer Website Hosting zur Ausführung der Funktion bigben weiter:

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

Funktionsweise von region im Block function

Wenn region in einem function-Block der hosting.rewrites-Konfiguration fehlt, versucht die Firebase-Befehlszeile, die Region automatisch aus dem Quellcode der Funktion zu ermitteln. Wenn keine Region angegeben ist, wird standardmäßig us-central1 verwendet. Wenn der Quellcode der Funktion nicht verfügbar ist, versucht die Befehlszeile, die Region anhand der bereitgestellten Funktion zu ermitteln. Wenn sich die Funktion in mehreren Regionen befindet, muss in der hosting.rewrites-Konfiguration region in der Befehlszeile angegeben werden.

Funktionsweise von pinTag im Block function

Die pinTag-Funktion ist nur auf Cloud Functions for Firebase (2. Generation) verfügbar. Mit dieser Funktion können Sie dafür sorgen, dass alle Funktionen zum Generieren der dynamischen Inhalte Ihrer Website mit Ihren statischen Hosting-Ressourcen und der Hosting-Konfiguration synchronisiert bleiben. Außerdem können Sie mit dieser Funktion Ihre Funktionen in der Vorschau auf Hosting-Vorschaukanälen ansehen.

Wenn Sie einem function-Block der hosting.rewrites-Konfiguration "pinTag": true hinzufügen, wird die angepinnte Funktion zusammen mit Ihren statischen Hosting-Ressourcen und der Hosting-Konfiguration bereitgestellt, auch wenn firebase deploy --only hosting ausgeführt wird. Wenn Sie eine Version Ihrer Website rückgängig machen, wird auch die Funktion „Angepinnt“ rückgängig gemacht.

Hinweis: Wenn Sie einer vorhandenen Neufassung eine pinTag hinzufügen, müssen Sie die aktualisierte Neufassung zuerst auf Ihrem „Live“-Kanal bereitstellen. Nach der Bereitstellung können Sie Änderungen am Code Ihrer Funktion in Hosting-Vorschaukanälen in der Vorschau ansehen, ohne dass sie sich auf die Produktion auswirken.

Diese Funktion basiert auf Cloud Run-Tags, die auf 1.000 Tags pro Dienst und 2.000 Tags pro Region beschränkt sind. Das bedeutet, dass nach Hunderten von Bereitstellungen die ältesten Versionen einer Website möglicherweise nicht mehr funktionieren.

Nachdem Sie diese Umschreibregel hinzugefügt und die Funktion mit firebase deploy auf Firebase bereitgestellt haben, ist sie über die folgenden URLs erreichbar:

• Ihre Firebase-Subdomains:
  PROJECT_ID.web.app/bigben und PROJECT_ID.firebaseapp.com/bigben

• Alle verbundenen benutzerdefinierten Domains:
  CUSTOM_DOMAIN/bigben

Wenn Anfragen mit Hosting an Funktionen weitergeleitet werden, sind die unterstützten HTTP-Anfragemethoden GET, POST, HEAD, PUT, DELETE, PATCH und OPTIONS. Andere Methoden wie REPORT oder PROFIND werden nicht unterstützt.

Anfragen an einen Cloud Run-Container weiterleiten

Mit rewrites können Sie über eine Firebase Hosting-URL auf einen Cloud Run-Container zugreifen. Das folgende Beispiel ist ein Auszug aus Dynamische Inhalte mit Cloud Run ausliefern.

So können Sie beispielsweise alle Anfragen von der Seite /helloworld auf Ihrer Website Hosting weiterleiten, um das Starten und Ausführen einer helloworld-Containerinstanz auszulösen:

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

Funktionsweise von pinTag im Block run

Mit dieser Funktion können Sie dafür sorgen, dass die Version Ihres Cloud Run-Dienstes zum Generieren der dynamischen Inhalte Ihrer Website mit Ihren statischen Hosting-Ressourcen und der Hosting-Konfiguration synchronisiert bleibt. Außerdem kannst du mit dieser Funktion eine Vorschau deiner Cloud Run-Neufassungen in Hosting-Vorschaukanälen ansehen.

Wenn Sie einem run-Block der hosting.rewrites-Konfiguration "pinTag": true hinzufügen, werden Ihre statischen Hosting-Ressourcen und ‑Konfiguration zum Zeitpunkt der Bereitstellung an die neueste Version des Cloud Run-Dienstes angepinnt. Wenn Sie eine Version Ihrer Website rückgängig machen, wird auch die Version des angepinnten Cloud Run-Dienstes rückgängig gemacht.

Diese Funktion basiert auf Cloud Run-Tags, die auf 1.000 Tags pro Dienst und 2.000 Tags pro Region beschränkt sind. Das bedeutet, dass nach Hunderten von Bereitstellungen die ältesten Versionen einer Website möglicherweise nicht mehr funktionieren.

Nachdem Sie diese Umschreibregel hinzugefügt und Ihr Container-Image mit firebase deploy auf Firebase bereitgestellt haben, ist es über die folgenden URLs erreichbar:

• Ihre Firebase-Subdomains:
  PROJECT_ID.web.app/helloworld und PROJECT_ID.firebaseapp.com/helloworld

• Alle verbundenen benutzerdefinierten Domains:
  CUSTOM_DOMAIN/helloworld

Bei der Weiterleitung von Anfragen an Cloud Run-Container mit Hosting werden die HTTP-Anfragemethoden GET, POST, HEAD, PUT, DELETE, PATCH und OPTIONS unterstützt. Andere Methoden wie REPORT oder PROFIND werden nicht unterstützt.

Für eine optimale Leistung sollten Sie Ihren Cloud Run-Dienst mit Hosting in den folgenden Regionen platzieren:

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

Weiterleitungen von Hosting zu Cloud Run werden in den folgenden Regionen unterstützt:

• 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

Benutzerdefinierte Domain erstellen Dynamic Links

Sie können rewrites verwenden, um die benutzerdefinierte Domain Dynamic Links zu erstellen. In der Dynamic Links-Dokumentation finden Sie detaillierte Informationen zum Einrichten einer benutzerdefinierten Domain für Dynamic Links.

• Verwenden Sie Ihre benutzerdefinierte Domain nur für 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
    } ]
  }
  

• Benutzerdefinierte Domainpfadpräfixe für Dynamic Links angeben

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

Für die Konfiguration von Dynamic Links in der firebase.json-Datei ist Folgendes erforderlich:

Feld		Beschreibung
appAssociation		Für dieses Feld muss AUTO festgelegt werden. Wenn Sie dieses Attribut nicht in Ihre Konfiguration aufnehmen, ist AUTO der Standardwert für appAssociation. Wenn Sie dieses Attribut auf AUTO festlegen, kann Hosting assetlinks.json- und apple-app-site-association-Dateien dynamisch generieren, wenn sie angefordert werden.
rewrites
	source	Einen Pfad, den Sie für Dynamic Links verwenden möchten Im Gegensatz zu Regeln, die Pfade in URLs umschreiben, dürfen Umschreibregeln für Dynamic Links keine regulären Ausdrücke enthalten.
	dynamicLinks	Für dieses Feld muss true festgelegt werden.

Wichtig: Bei Dynamic Links ist die Prioritätsreihenfolge des Hostings besonders wichtig.

• Das Dynamic Links-URL-Präfix darf nicht mit Hostingkonfigurationen mit höherer Priorität in Konflikt stehen. Beispielsweise haben gehostete statische Inhalte immer Vorrang vor Umschreibungen.
• Innerhalb der Attribute redirects und rewrites wendet Hosting die Weiterleitung oder Umschreibung an, die durch die erste Regel mit einem URL-Muster definiert ist, das mit dem angeforderten Pfad übereinstimmt. Sie müssen die Regeln in den einzelnen redirects- und rewrites-Attributen also bewusst anordnen.

Weitere Informationen finden Sie in der Dokumentation zu Dynamic Links.

Header konfigurieren

Optional
Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer Anfrage oder Antwort zu übergeben. Einige Header können sich darauf auswirken, wie der Browser die Seite und ihren Inhalt verarbeitet, einschließlich Zugriffssteuerung, Authentifizierung, Caching und Codierung.

Sie können benutzerdefinierte, dateispezifische Antwortheader angeben, indem Sie ein headers-Attribut erstellen, das ein Array von Headerobjekten enthält. Geben Sie in jedem Objekt ein URL-Muster an, das Hosting dazu veranlasst, die angegebenen benutzerdefinierten Antwortheader anzuwenden, wenn es mit dem URL-Pfad der Anfrage übereinstimmt.

Hier ist die grundlegende Struktur für ein headers-Attribut. In diesem Beispiel wird ein CORS-Header auf alle Schriftdateien angewendet.

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

Detailliertes Beispiel für ein headers-Attribut

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

Das headers-Attribut enthält ein Array von Definitionen, wobei jede Definition die Felder in der folgenden Tabelle enthalten muss.

Feld			Beschreibung
headers
	source (empfohlen) oder regex		Ein URL-Muster, das bei Übereinstimmung mit der URL der ursprünglichen Anfrage Hosting auslöst, um den benutzerdefinierten Header anzuwenden Verwenden Sie source, um einen Globus (empfohlen) anzugeben. Verwenden Sie regex, um einen regulären RE2-Ausdruck anzugeben. Wenn Sie eine Überschrift erstellen möchten, die mit Ihrer benutzerdefinierten 404-Seite abgeglichen werden soll, verwenden Sie 404.html als source- oder regex-Wert.
	Array von (untergeordneten) headers		Die benutzerdefinierten Header, die Hosting auf den Anfragepfad anwendet Jeder Zwischentitel muss ein key- und ein value-Paar enthalten (siehe nächste zwei Zeilen).
		key	Der Name des Headers, z. B. Cache-Control
		value	Der Wert für den Header, z. B. max-age=7200

Hinweis: Die URL-Musterübereinstimmung für benutzerdefinierte Header erfolgt vor der Anwendung von Umschreibregeln.

Weitere Informationen zu Cache-Control finden Sie im Abschnitt Hosting, in dem das Bereitstellen dynamischer Inhalte und das Hosten von Microservices beschrieben wird. Weitere Informationen zu CORS-Headern

Wichtig :Firebase Hosting überschreibt die Strict-Transport-Security-Konfiguration auf Standard-Hosting-Subdomains (z. B. *.web.app). Für alle verbundenen benutzerdefinierten Domains wird jedoch der konfigurierte Wert verwendet.

.html-Erweiterungen verwalten

Optional
Mit dem Attribut cleanUrls können Sie festlegen, ob URLs die Erweiterung .html enthalten sollen.

Wenn true, entfernt Hosting automatisch die .html-Erweiterung aus den URLs der hochgeladenen Dateien. Wenn in der Anfrage eine .html-Erweiterung hinzugefügt wird, führt Hosting eine 301-Weiterleitung zum selben Pfad aus, entfernt aber die .html-Erweiterung.

So kannst du die Aufnahme von .html in URLs steuern, indem du ein cleanUrls-Attribut hinzufügst:

"hosting": {
  // ...

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

Schlussschrägstriche steuern

Optional
Mit dem Attribut trailingSlash können Sie festlegen, ob URLs für statische Inhalte Schlussschrägstriche enthalten sollen.

• Wenn true, Hosting URLs weiterleitet, um einen abschließenden Schrägstrich hinzuzufügen.
• Wenn false, Hosting URLs weiterleitet, um einen abschließenden Schrägstrich zu entfernen.
• Wenn keine Angabe erfolgt, verwendet Hosting nur abschließende Schrägstriche für Verzeichnisindexdateien (z. B. about/index.html).

So steuern Sie Schlussschrägstriche, indem Sie ein trailingSlash-Attribut hinzufügen:

"hosting": {
  // ...

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

Das Attribut trailingSlash hat keine Auswirkungen auf Umschreibungen für dynamische Inhalte, die über Cloud Functions oder Cloud Run ausgeliefert werden.

Glob-Musterabgleich

Bei den Firebase Hosting-Konfigurationsoptionen wird die Notation für das Globus-Mustervergleich mit extglob häufig verwendet. Das entspricht der Verarbeitung von gitignore-Regeln in Git und von ignore-Regeln in Bower. Diese Wiki-Seite enthält eine ausführlichere Referenz. Im Folgenden werden die auf dieser Seite verwendeten Beispiele erläutert:

• firebase.json – stimmt nur mit der Datei firebase.json im Stammverzeichnis des Verzeichnisses public überein

• ** – stimmt mit jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis überein

• * – trifft nur auf Dateien und Ordner im Stammverzeichnis des Verzeichnisses public zu

• **/.*: Entspricht allen Dateien, die mit . beginnen (in der Regel ausgeblendete Dateien wie im Ordner .git) in einem beliebigen Unterverzeichnis.

• **/node_modules/**: Entspricht jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis eines node_modules-Ordners, der sich selbst in einem beliebigen Unterverzeichnis des Verzeichnisses public befinden kann.

• **/*.@(jpg|jpeg|gif|png): Damit werden alle Dateien in einem beliebigen Unterverzeichnis gefunden, die genau auf einen der folgenden Werte enden: .jpg, .jpeg, .gif oder .png.

Vollständiges Hosting-Konfigurationsbeispiel

Das folgende Beispiel zeigt eine vollständige firebase.json-Konfiguration für Firebase Hosting. Eine firebase.json-Datei kann auch Konfigurationen für andere Firebase-Dienste enthalten.

{
  "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",

  }
}