Konfigurieren Sie das Hosting-Verhalten

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

Was können Sie für das Hosting konfigurieren?

• Geben Sie an, welche Dateien in Ihrem lokalen Projektverzeichnis Sie auf Firebase Hosting bereitstellen möchten. Lernen wie.

• Stellen Sie eine angepasste 404/Nicht gefunden-Seite bereit. Lernen wie.

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

• Richten Sie rewrites für einen dieser Zwecke ein:

  • Zeigen Sie denselben Inhalt für mehrere URLs an. Lernen wie.

  • Stellen Sie eine Funktion bereit oder greifen Sie über eine Hosting-URL auf einen Cloud Run-Container zu. Erfahren Sie, wie: Funktion oder Container .

  • Erstellen Sie einen benutzerdefinierten Domänen-Dynamic Link. Lernen wie.

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

• Richten Sie Umschreibungen für die Internationalisierung (i18n) ein, um spezifische Inhalte basierend auf der Sprachpräferenz und/oder dem Land eines Benutzers bereitzustellen. Erfahren Sie wie (andere Seite).

Wo definieren Sie Ihre Hosting-Konfiguration?

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

Achtung: Wenn Sie firebase init erneut ausführen und „Hosting“ auswählen, überschreibt der Befehl den hosting Abschnitt der Datei firebase.json “ und setzt ihn wieder auf die Standardkonfiguration zurück.

Unten auf dieser Seite finden Sie ein vollständiges Beispiel für die Konfiguration firebase.json (das nur Firebase Hosting abdeckt). Beachten Sie, dass eine firebase.json Datei auch Konfigurationen für andere Firebase-Dienste enthalten kann.

Sie können den bereitgestellten Inhalt firebase.json mithilfe der Hosting-REST-API überprüfen.

Prioritätsreihenfolge der Hosting-Antworten

Die verschiedenen auf dieser Seite beschriebenen Konfigurationsoptionen für Firebase Hosting können sich manchmal überschneiden. Im Falle eines Konflikts bestimmt das Hosting seine Reaktion anhand der folgenden Prioritätsreihenfolge:

1. Reservierte Namespaces, die mit einem /__/* Pfadsegment beginnen
2. Konfigurierte Weiterleitungen
3. Genau passender statischer Inhalt
4. Konfigurierte Umschreibungen
5. Benutzerdefinierte 404- Seite
6. Standard-404-Seite

Wichtig: Innerhalb jedes redirects und rewrites wendet Hosting die durch die erste Regel definierte Umleitung oder Umschreibung mit einem URL-Muster an, das dem angeforderten Pfad entspricht. Daher müssen Sie die Regeln innerhalb der einzelnen redirects und rewrites bewusst ordnen. Konfigurierte redirects haben weiterhin Vorrang vor rewrites .

Wenn Sie i18n-Umschreibungen verwenden, wird der Umfang der Prioritätsreihenfolge für exakte Übereinstimmung und 404-Behandlung erweitert, um Ihren „i18n-Inhalt“ zu berücksichtigen.

Geben Sie an, welche Dateien bereitgestellt werden sollen

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

Die Standard- hosting Konfiguration in einer Datei firebase.json sieht folgendermaßen aus:

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

öffentlich

Erforderlich
Das public Attribut gibt an, welches Verzeichnis auf 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 dieser in Ihrem Projektverzeichnis vorhanden ist.

Das Folgende ist der standardmäßig angegebene Name des bereitzustellenden Verzeichnisses:

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

  // ...
}

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

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

  // ...
}

ignorieren

Optional
Das Attribut ignore gibt die Dateien an, die bei der Bereitstellung ignoriert werden sollen. Es kann Globs auf die gleiche Weise annehmen, wie Git mit .gitignore umgeht.

Im Folgenden sind die Standardwerte für die zu ignorierenden Dateien aufgeführt:

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

Passen Sie eine 404/Nicht gefunden-Seite an

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

Erstellen Sie eine neue Datei im public Verzeichnis Ihres Projekts, nennen Sie sie 404.html und fügen Sie dann Ihren benutzerdefinierten 404 Not Found Inhalt zur Datei hinzu.

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

Weiterleitungen konfigurieren

Optional
Verwenden Sie eine URL-Umleitung, um fehlerhafte Links zu verhindern, wenn Sie eine Seite verschoben haben, oder um URLs zu kürzen. Beispielsweise könnten Sie einen Browser von example.com/team zu example.com/about.html umleiten.

Geben Sie URL-Weiterleitungen an, indem Sie ein redirects erstellen, das ein Array von Objekten enthält (sogenannte „Umleitungsregeln“). Geben Sie in jeder Regel ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting dazu veranlasst, mit einer Weiterleitung an die angegebene Ziel-URL zu antworten.

Hier ist die Grundstruktur für ein redirects . In diesem Beispiel werden Anfragen an /foo umgeleitet, indem eine neue Anfrage an /bar gestellt wird.

"hosting": {
  // ...

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

Sehen Sie sich ein detaillierteres Beispiel für ein redirects an

"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 Attribut redirects enthält ein Array von Umleitungsregeln, wobei jede Regel die Felder in der folgenden Tabelle enthalten muss.

Firebase Hosting vergleicht den source oder regex Wert zu Beginn jeder Anfrage mit allen URL-Pfaden (bevor der Browser feststellt, ob eine Datei oder ein Ordner in diesem Pfad vorhanden ist). Wenn eine Übereinstimmung gefunden wird, sendet der Firebase Hosting-Ursprungsserver eine HTTPS-Umleitungsantwort, die den Browser auffordert, eine neue Anfrage an die destination URL zu stellen.

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

Wichtig: Innerhalb des redirects wendet Hosting die durch die erste Regel definierte Umleitung mit einem URL-Muster an, das dem angeforderten Pfad entspricht. Sie müssen die Regeln also bewusst innerhalb des redirects ordnen.

Erfassen Sie URL-Segmente für Weiterleitungen

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

Erfassen Sie URL-Segmente, wenn Sie Globs verwenden

Wenn Sie ein source verwenden (d. h. einen Glob für Ihr URL-Muster angeben), können Sie Segmente erfassen, indem Sie ein : -Präfix einfügen, um das Segment zu identifizieren. Wenn Sie auch den verbleibenden URL-Pfad nach dem Segment erfassen müssen, fügen Sie unmittelbar nach dem Segment ein * ein. Zum 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
  } ]
}

Erfassen Sie URL-Segmente, wenn Sie reguläre RE2-Ausdrücke verwenden

Wenn Sie ein regex Feld verwenden (d. h. einen regulären RE2-Ausdruck für Ihr URL-Muster angeben), können Sie Segmente entweder mit benannten oder unbenannten RE2-Erfassungsgruppen erfassen. Benannte Capture-Gruppen können im destination mit dem Präfix : verwendet werden, während unbenannte Capture-Gruppen durch ihren numerischen Index im regex Wert referenziert werden können, der ab 1 indiziert wird. 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
  } ]
}

Konfigurieren Sie Umschreibungen

Optional
Verwenden Sie eine Umschreibung, um denselben Inhalt für mehrere URLs anzuzeigen. Umschreibungen sind beim Mustervergleich besonders nützlich, da Sie jede URL akzeptieren können, die dem Muster entspricht, und den clientseitigen Code entscheiden lassen können, was angezeigt werden soll.

Sie können Rewrites auch verwenden, um Apps zu unterstützen, die HTML5 pushState für die Navigation verwenden. Wenn ein Browser versucht, einen URL-Pfad zu öffnen, der dem angegebenen source oder regex -URL-Muster entspricht, erhält der Browser stattdessen den Inhalt der Datei unter der destination URL.

Geben Sie URL-Rewrites an, indem Sie ein rewrites Attribut erstellen, das ein Array von Objekten enthält (sogenannte „Rewrite-Regeln“). Geben Sie in jeder Regel ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting dazu veranlasst, zu reagieren, als ob dem Dienst die angegebene Ziel-URL gegeben worden wäre.

Hier ist die Grundstruktur 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"
  } ]
}

Sehen Sie sich ein detaillierteres Beispiel für ein rewrites Attribut an

"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 Rewrite-Regeln, wobei jede Regel die Felder in der folgenden Tabelle enthalten muss.

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

Feld		Beschreibung
rewrites
	source (empfohlen) oder regex	Ein URL-Muster, das, wenn es mit der ursprünglichen Anforderungs-URL übereinstimmt, Hosting dazu veranlasst, die Umschreibung anzuwenden Verwenden Sie source , um einen Glob anzugeben (empfohlen) . Verwenden Sie regex um einen regulären RE2-Ausdruck anzugeben.
	destination	Eine lokale Datei, die vorhanden sein muss Diese URL kann ein relativer oder ein absoluter Pfad sein.

Wichtig: Innerhalb des rewrites Attributs wendet Hosting das durch die erste Regel definierte Rewrite mit einem URL-Muster an, das dem angeforderten Pfad entspricht. Sie müssen die Regeln also bewusst innerhalb des rewrites Attributs anordnen.

Direkte Anfragen an eine Funktion

Sie können rewrites verwenden, um eine Funktion über eine Firebase-Hosting-URL bereitzustellen. Das folgende Beispiel ist ein Auszug aus der Bereitstellung dynamischer Inhalte mithilfe von Cloud Functions .

Um beispielsweise alle Anfragen von der Seite /bigben auf Ihrer Hosting-Site an die Ausführung der bigben Funktion weiterzuleiten:

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

Wie region innerhalb des function funktioniert

Wenn region in einem function der hosting.rewrites Konfiguration weggelassen wird, versucht die Firebase-CLI, die Region automatisch aus dem Quellcode der Funktion zu erkennen, der, wenn nicht angegeben, standardmäßig us-central1 ist. Wenn der Quellcode der Funktion nicht verfügbar ist, versucht die CLI, die Region anhand der bereitgestellten Funktion zu erkennen. Wenn sich die Funktion in mehreren Regionen befindet, erfordert die CLI die Angabe der region in der hosting.rewrites Konfiguration.

Wie pinTag innerhalb des function funktioniert

Die pinTag Funktion ist nur in Cloud Functions für Firebase (2. Generation) verfügbar. Mit dieser Funktion können Sie sicherstellen, dass jede Funktion zum Generieren des dynamischen Inhalts Ihrer Website mit Ihren statischen Hosting-Ressourcen und Ihrer Hosting-Konfiguration synchronisiert bleibt. Mit dieser Funktion können Sie außerdem eine Vorschau Ihrer neu geschriebenen Funktionen auf Hosting-Vorschaukanälen anzeigen.

Wenn Sie "pinTag": true zu einem function der hosting.rewrites Konfiguration hinzufügen, wird die „pinned“-Funktion zusammen mit Ihren statischen Hosting-Ressourcen und Ihrer Konfiguration bereitgestellt, selbst wenn Sie firebase deploy --only hosting ausführen. Wenn Sie eine Version Ihrer Website zurücksetzen, wird auch die Funktion „Angeheftet“ zurückgesetzt.

Hinweis: Wenn Sie einem vorhandenen Rewrite einen pinTag hinzufügen, müssen Sie den aktualisierten Rewrite zunächst in Ihrem „Live“-Kanal bereitstellen. Nach der Bereitstellung können Sie in den Hosting-Vorschaukanälen eine Vorschau der Änderungen am Code Ihrer Funktion anzeigen, ohne dass dies Auswirkungen auf die Produktion hat.

Diese Funktion basiert auf Cloud Run-Tags , für die ein Limit von 1.000 Tags pro Dienst und 2.000 Tags pro Region gilt. Das bedeutet, dass nach Hunderten von Bereitstellungen die ältesten Versionen einer Site möglicherweise nicht mehr funktionieren.

Nachdem Sie diese Rewrite-Regel hinzugefügt und in Firebase bereitgestellt haben (mithilfe von firebase deploy ), ist Ihre Funktion über die folgenden URLs erreichbar:

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

• Alle verbundenen benutzerdefinierten Domänen :
  CUSTOM_DOMAIN /bigben

Beim Umleiten von Anforderungen an Funktionen mit Hosting sind die unterstützten HTTP-Anforderungsmethoden GET , POST , HEAD , PUT , DELETE , PATCH und OPTIONS . Andere Methoden wie REPORT oder PROFIND werden nicht unterstützt.

Direkte Anfragen an einen Cloud Run-Container

Sie können rewrites verwenden, um über eine Firebase-Hosting-URL auf einen Cloud Run-Container zuzugreifen. Das folgende Beispiel ist ein Auszug aus der Bereitstellung dynamischer Inhalte mit Cloud Run .

Um beispielsweise alle Anfragen von der Seite /helloworld auf Ihrer Hosting-Site so weiterzuleiten, dass sie den Start und die Ausführung einer helloworld Containerinstanz auslö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)
   }
 } ]
}

So funktioniert pinTag innerhalb des run

Mit dieser Funktion können Sie sicherstellen, dass die Revision Ihres Cloud Run-Dienstes zum Generieren des dynamischen Inhalts Ihrer Website mit Ihren statischen Hosting-Ressourcen und Ihrer Hosting-Konfiguration synchronisiert bleibt. Außerdem können Sie mit dieser Funktion eine Vorschau Ihrer Neufassungen in den Vorschaukanälen von Cloud Run auf Hosting anzeigen.

Wenn Sie "pingTag": true zu einem run der hosting.rewrites Konfiguration hinzufügen, werden Ihre statischen Hosting-Ressourcen und Ihre Konfiguration zum Zeitpunkt der Bereitstellung an die aktuellste Revision des Cloud Run-Dienstes angeheftet. Wenn Sie eine Version Ihrer Site zurücksetzen, wird auch die Revision des „angehefteten“ Cloud Run-Dienstes zurückgesetzt.

Diese Funktion basiert auf Cloud Run-Tags , für die ein Limit von 1.000 Tags pro Dienst und 2.000 Tags pro Region gilt. Das bedeutet, dass nach Hunderten von Bereitstellungen die ältesten Versionen einer Site möglicherweise nicht mehr funktionieren.

Nachdem Sie diese Rewrite-Regel hinzugefügt und in Firebase bereitgestellt haben (mithilfe von firebase deploy ), ist Ihr Container-Image über die folgenden URLs erreichbar:

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

• Alle verbundenen benutzerdefinierten Domänen :
  CUSTOM_DOMAIN /helloworld

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

Um die beste Leistung zu erzielen, platzieren Sie Ihren Cloud Run-Dienst mit Hosting in den folgenden Regionen:

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

Umschreibungen in Cloud Run vom Hosting 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

Erstellen Sie benutzerdefinierte dynamische Domänenlinks

Sie können rewrites verwenden, um benutzerdefinierte dynamische Domänenlinks zu erstellen. Ausführliche Informationen zum Einrichten einer benutzerdefinierten Domäne für Dynamic Links finden Sie in der Dynamic Links-Dokumentation.

• Verwenden Sie Ihre benutzerdefinierte Domäne nur für dynamische 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
    } ]
  }
  

• Geben Sie benutzerdefinierte Domänenpfadpräfixe an, die für dynamische Links verwendet werden sollen

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

Das Konfigurieren dynamischer Links in Ihrer firebase.json Datei erfordert Folgendes:

Feld		Beschreibung
appAssociation		Muss auf AUTO eingestellt sein Wenn Sie dieses Attribut nicht in Ihre Konfiguration einbeziehen, ist der Standardwert für appAssociation AUTO . Durch Festlegen dieses Attributs auf AUTO kann Hosting bei Anforderung dynamisch assetlinks.json und apple-app-site-association Dateien generieren.
rewrites
	source	Ein Pfad, den Sie für dynamische Links verwenden möchten Im Gegensatz zu Regeln, die Pfade zu URLs umschreiben, können Umschreibungsregeln für dynamische Links keine regulären Ausdrücke enthalten.
	dynamicLinks	Muss auf true gesetzt sein

Wichtig : Achten Sie bei dynamischen Links besonders auf die Reihenfolge der Hosting-Priorität .

• Stellen Sie sicher, dass Ihr URL-Präfix für dynamische Links nicht mit Hosting-Konfigurationen mit höherer Priorität in Konflikt steht (z. B. haben gehostete statische Inhalte immer Vorrang vor Umschreibungen).
• Innerhalb jedes redirects und rewrites wendet Hosting die durch die erste Regel definierte Umleitung oder Umschreibung mit einem URL-Muster an, das dem angeforderten Pfad entspricht. Daher müssen Sie die Regeln innerhalb der einzelnen redirects und rewrites bewusst ordnen.

Ausführliche Informationen finden Sie in der Dynamic Links-Dokumentation .

Header konfigurieren

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

Geben Sie benutzerdefinierte, dateispezifische Antwortheader an, indem Sie ein headers Attribut erstellen, das ein Array von Header-Objekten enthält. Geben Sie in jedem Objekt ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting dazu veranlasst, die angegebenen benutzerdefinierten Antwortheader anzuwenden.

Hier ist die Grundstruktur für ein headers Attribut. In diesem Beispiel wird ein CORS-Header für alle Schriftartdateien 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": "*"
    } ]
  } ]
}

Sehen Sie sich ein detaillierteres Beispiel für ein headers Attribut an

"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 ursprünglichen Anforderungs-URL Hosting dazu veranlasst, den benutzerdefinierten Header anzuwenden Verwenden Sie source , um einen Glob anzugeben (empfohlen) . Verwenden Sie regex um einen regulären RE2-Ausdruck anzugeben. Um einen Header zu erstellen, der mit Ihrer benutzerdefinierten 404-Seite übereinstimmt, verwenden Sie 404.html als source oder regex -Wert.
	Array von (Unter-) headers		Die benutzerdefinierten Header, die Hosting auf den Anforderungspfad anwendet Jeder Unterkopf muss ein key - value Paar enthalten (siehe die nächsten beiden Zeilen).
		key	Der Name des Headers, zum Beispiel Cache-Control
		value	Der Wert für den Header, zum Beispiel max-age=7200

Hinweis: Der URL-Musterabgleich für benutzerdefinierte Header erfolgt , bevor Umschreibungsregeln angewendet werden.

Weitere Informationen zu Cache-Control finden Sie im Abschnitt „Hosting“, in dem die Bereitstellung dynamischer Inhalte und das Hosten von Mikrodiensten beschrieben wird. Sie können auch mehr über CORS- Header erfahren.

Wichtig: Firebase Hosting überschreibt die Strict-Transport-Security Konfiguration auf Standard-Hosting-Subdomains (wie *.web.app ). Alle verbundenen benutzerdefinierten Domänen stellen jedoch den konfigurierten Wert bereit.

Steuern Sie .html Erweiterungen

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

Bei true löscht Hosting automatisch die Erweiterung .html aus den URLs hochgeladener Dateien. Wenn der Anfrage eine .html Erweiterung hinzugefügt wird, führt Hosting eine 301 Umleitung zum gleichen Pfad durch, entfernt jedoch die .html Erweiterung.

So steuern Sie die Einbeziehung von .html in URLs, indem Sie ein cleanUrls Attribut einfügen:

"hosting": {
  // ...

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

Kontrollieren Sie abschließende Schrägstriche

Optional
Mit dem Attribut trailingSlash können Sie steuern, ob statische Inhalts-URLs abschließende Schrägstriche enthalten sollen.

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

So steuern Sie abschließende Schrägstriche durch Hinzufügen eines Attributs trailingSlash :

"hosting": {
  // ...

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

Das Attribut trailingSlash wirkt sich nicht auf Umschreibungen dynamischer Inhalte aus, die von Cloud Functions oder Cloud Run bereitgestellt werden.

Glob-Mustervergleich

Die Konfigurationsoptionen von Firebase Hosting nutzen in großem Umfang die Glob-Mustervergleichsnotation mit extglob, ähnlich wie Git gitignore Regeln und Bower ignore Regeln verarbeitet. Diese Wiki-Seite ist eine ausführlichere Referenz, im Folgenden finden Sie jedoch Erläuterungen zu den auf dieser Seite verwendeten Beispielen:

• firebase.json – Entspricht nur der Datei firebase.json im Stammverzeichnis des public Verzeichnisses

• ** – Entspricht jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis

• * – Entspricht nur Dateien und Ordnern im Stammverzeichnis des public Verzeichnisses

• **/.* – Entspricht jeder Datei, die mit beginnt . (normalerweise versteckte Dateien, wie im .git Ordner) 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 public Verzeichnisses befinden kann

• **/*.@(jpg|jpeg|gif|png) – Entspricht jeder Datei in einem beliebigen Unterverzeichnis, die mit genau einer der folgenden Dateien endet: .jpg , .jpeg , .gif oder .png

Vollständiges Hosting-Konfigurationsbeispiel

Im Folgenden finden Sie ein vollständiges firebase.json Konfigurationsbeispiel für Firebase Hosting. Beachten Sie, dass eine firebase.json Datei auch Konfigurationen für andere Firebase-Dienste enthalten kann.

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

  }
}