Diese Seite wurde von der Cloud Translation API übersetzt.

Konfigurieren Sie das Hosting-Verhalten

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

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

Geben Sie an, welche Dateien in Ihrem lokalen Projektverzeichnis Sie für Firebase Hosting bereitstellen möchten. Lernen wie.
Stellen Sie eine angepasste 404/Not Found-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 der folgenden Zwecke ein:
- Zeigen Sie denselben Inhalt für mehrere URLs an. Lernen wie.
- Führen Sie eine Funktion aus oder greifen Sie über eine Hosting-URL auf einen Cloud Run-Container zu. Erfahren Sie, wie: function oder container .
- Erstellen Sie einen dynamischen Link für eine benutzerdefinierte Domain. 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 bestimmte 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 firebase.json Datei. Firebase erstellt automatisch Ihre firebase.json Datei im Stammverzeichnis Ihres Projektverzeichnisses, wenn Sie den firebase init Befehl ausführen.

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

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

Prioritätsreihenfolge der Hosting-Antworten

Die verschiedenen auf dieser Seite beschriebenen Konfigurationsoptionen für das Firebase-Hosting können sich manchmal überschneiden. Wenn es einen Konflikt gibt, bestimmt Hosting seine Antwort anhand der folgenden Prioritätsreihenfolge:

Reservierte Namespaces, die mit einem Pfadsegment /__/* beginnen
Konfigurierte Weiterleitungen
Statischer Inhalt mit exakter Übereinstimmung
Konfigurierte Umschreibungen
Benutzerdefinierte 404- Seite
Standard-404-Seite

Wenn Sie i18n-Umschreibungen verwenden, werden die Reihenfolge der Prioritäten für die exakte Übereinstimmung und die 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 standardmäßige hosting Konfiguration in einer firebase.json Datei 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 für Firebase Hosting bereitgestellt werden soll. Der Standardwert ist ein Verzeichnis namens public , aber Sie können den Pfad eines beliebigen Verzeichnisses angeben, solange es in Ihrem Projektverzeichnis vorhanden ist.

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

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

  // ...
}

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

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

  // ...
}

ignorieren

Optional
Das ignore Attribut gibt die Dateien an, die bei der Bereitstellung ignoriert werden sollen. Es kann Globs genauso verarbeiten wie Git .gitignore .

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/Not Found-Seite an

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

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 einen 404 Not Found Fehler auf Ihrer Domain oder Subdomain 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 auf example.com/about.html umleiten.

Geben Sie URL-Umleitungen 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 grundlegende Struktur für ein redirects . Dieses Beispiel leitet Anfragen an /foo um, 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 ausführlicheres 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 Weiterleitungsregeln, 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 bestimmt, ob eine Datei oder ein Ordner unter diesem Pfad vorhanden ist). Wenn eine Übereinstimmung gefunden wird, sendet der Ursprungsserver von Firebase Hosting eine HTTPS-Umleitungsantwort, die den Browser anweist, eine neue Anfrage an die destination URL zu stellen.

Feld		Beschreibung
`redirects`
	`source` (empfohlen) oder `regex`	Ein URL-Muster, das, wenn es mit der ursprünglichen Anforderungs-URL übereinstimmt, Hosting veranlasst, die Weiterleitung anzuwenden Verwenden Sie `source` , um ein Glob anzugeben (empfohlen) . Verwenden Sie `regex` um einen regulären RE2-Ausdruck anzugeben.
	`destination`	Eine statische URL, an der der Browser eine neue Anfrage stellen soll Diese URL kann ein relativer oder 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)

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 mit benannten oder unbenannten RE2-Erfassungsgruppen erfassen. Benannte Erfassungsgruppen können im destination mit einem : -Präfix verwendet werden, während unbenannte Erfassungsgruppen durch ihren numerischen Index im regex Wert referenziert werden können, indiziert ab 1. 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
Verwenden Sie eine Umschreibung, um denselben Inhalt für mehrere URLs anzuzeigen. Umschreibungen sind besonders nützlich beim 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 Umschreibungen 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 mit dem angegebenen source oder regex -URL-Muster übereinstimmt, erhält der Browser stattdessen den Inhalt der Datei unter der destination URL.

Geben Sie URL-Umschreibungen an, indem Sie ein rewrites erstellen, das ein Array von Objekten enthält (als „Umschreibungsregeln“ bezeichnet). Geben Sie in jeder Regel ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting dazu veranlasst, so zu reagieren, als hätte der Dienst die angegebene Ziel-URL erhalten.

Hier ist die Grundstruktur für ein rewrites Attribut. Dieses Beispiel bedient index.html für Anfragen an Dateien oder Verzeichnisse, die nicht existieren.

"hosting": {
  // ...

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

Sehen Sie sich ein ausführlicheres 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 Attribut rewrites enthält ein Array von Rewrite-Regeln, wobei jede Regel die Felder in der folgenden Tabelle enthalten muss.

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

Feld Beschreibung

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 ein 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 absoluter Pfad sein.

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 ein 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 absoluter Pfad sein.

Direkte Anfragen an eine Funktion

Sie können rewrites verwenden, um eine Funktion von einer Firebase-Hosting-URL bereitzustellen. Das folgende Beispiel ist ein Auszug aus der Bereitstellung dynamischer Inhalte mit 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": "bigben",
    "region": "us-central1"  // optional (see note below)
  } ]
}

Nachdem Sie diese Umschreibungsregel hinzugefügt und in Firebase bereitgestellt haben (mit 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.

Anfragen an einen Cloud Run-Container leiten

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

Nachdem Sie diese Umschreibungsregel hinzugefügt und in Firebase bereitgestellt haben (mit 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.

Derzeit können Sie Cloud Run-Umschreibungen mit Hosting in den folgenden Regionen verwenden:

asia-east1
asia-east2
asia-northeast1
asia-northeast2
asia-northeast3
asia-south1
asia-southeast1
asia-southeast2
australia-southeast1
europe-north1
europe-west1
europe-west2
europe-west3
europe-west4
europe-west6
northamerica-northeast1
southamerica-east1
us-central1
us-east1
us-east4
us-west1

Erstellen Sie dynamische Links für benutzerdefinierte Domänen

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

Verwenden Sie Ihre benutzerdefinierte Domain 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 Präfixe für Domänenpfade 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 aufnehmen, ist der Standardwert für `appAssociation` `AUTO` . Durch Festlegen dieses Attributs auf `AUTO` kann Hosting `assetlinks.json` und `apple-app-site-association` Dateien dynamisch generieren, wenn sie angefordert werden.
`rewrites`
	`source`	Ein Pfad, den Sie für dynamische Links verwenden möchten Im Gegensatz zu Regeln, die Pfade in URLs umschreiben, können Umschreibungsregeln für dynamische Links keine regulären Ausdrücke enthalten.
	`dynamicLinks`	Muss auf `true` gesetzt werden

Header konfigurieren

Optional
Header ermöglichen es dem Client und dem Server, zusätzliche Informationen zusammen mit einer Anfrage oder einer Antwort weiterzugeben. Einige Kopfzeilensätze können sich darauf auswirken, wie der Browser die Seite und ihren Inhalt verarbeitet, einschließlich Zugriffskontrolle, Authentifizierung, Zwischenspeicherung 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 grundlegende Struktur für ein headers Attribut. Dieses Beispiel wendet einen CORS-Header auf alle Schriftartdateien an.

"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 ausführlicheres 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 ein 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 (Sub-) `headers`		Die benutzerdefinierten Header, die Hosting auf den Anforderungspfad anwendet Jeder Sub-Header muss ein `key` - `value` Paar enthalten (siehe nächste zwei Zeilen).
		`key`	Der Name des Headers, zum Beispiel `Cache-Control`
		`value`	Der Wert für den Header, zum Beispiel `max-age=7200`

Mehr über Cache-Control erfahren Sie im Abschnitt Hosting, in dem das Bereitstellen dynamischer Inhalte und das Hosten von Microservices beschrieben wird. Sie können auch mehr über CORS- Header erfahren.

Steuern Sie `.html` Erweiterungen

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

Wenn true , löscht Hosting automatisch die Erweiterung .html aus hochgeladenen Datei-URLs. Wenn der Anfrage eine .html Erweiterung hinzugefügt wird, führt Hosting eine 301 Weiterleitung zum selben Pfad durch, eliminiert 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 nachgestellte Schrägstriche enthalten sollen oder nicht.

Wenn true , leitet Hosting URLs um, um einen nachgestellten Schrägstrich hinzuzufügen.
Bei false leitet Hosting URLs um, um einen nachgestellten Schrägstrich zu entfernen.
Wenn nicht angegeben, verwendet Hosting nachgestellte Schrägstriche nur für Verzeichnisindexdateien (z. B. about/index.html ).

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

"hosting": {
  // ...

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

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

Glob-Musterabgleich

Die Konfigurationsoptionen von Firebase Hosting machen ausgiebigen Gebrauch von der Glob-Musterabgleichsnotation mit extglob, ähnlich wie Git gitignore Regeln und Bower ignore handhabt. Diese Wiki-Seite ist eine detailliertere Referenz, aber im Folgenden finden Sie Erläuterungen zu Beispielen, die auf dieser Seite verwendet werden:

firebase.json – Stimmt nur mit der Datei firebase.json im Stammverzeichnis des public Verzeichnisses überein
** — Stimmt mit jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis überein
* — Stimmt nur mit Dateien und Ordnern im Stammverzeichnis des public Verzeichnisses überein
**/.* — Entspricht jeder Datei, die mit . (normalerweise versteckte Dateien, wie im .git Ordner) in einem beliebigen Unterverzeichnis
**/node_modules/** — Stimmt mit jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis eines node_modules Ordners überein, der sich selbst in einem beliebigen Unterverzeichnis des public Verzeichnisses befinden kann
**/*.@(jpg|jpeg|gif|png) — Stimmt mit jeder Datei in einem beliebigen Unterverzeichnis überein, die auf genau eine der folgenden endet: .jpg , .jpeg , .gif oder .png

Beispiel für eine vollständige Hosting-Konfiguration

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

  }
}