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

• Richte redirects für Seiten ein, die du verschoben oder gelöscht hast. 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 Internationalisierungsüberschreibungen (i18n) ein, um bestimmte Inhalte je nach Spracheinstellung und/oder Land eines Nutzers bereitzustellen. 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.

Ein vollständiges firebase.json-Konfigurationsbeispiel (nur für Firebase Hosting) finden Sie unten auf dieser Seite. 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ätsreihenfolge von Hosting Antworten

Die auf dieser Seite beschriebenen verschiedenen Firebase Hosting-Konfigurationsoptionen können sich manchmal überschneiden. Wenn es einen Konflikt gibt, 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

Wenn Sie i18n-Umschreibungen verwenden, wird der Bereich der Prioritätsreihenfolge „Exakte Übereinstimmung“ und „404-Verarbeitung“ erweitert, um Ihren „i18n-Inhalt“ 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
Das Attribut public gibt an, 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.

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

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 eine neue Datei im public-Verzeichnis Ihres Projekts, nennen Sie sie 404.html und fügen Sie der Datei Ihren benutzerdefinierten 404 Not Found-Inhalt 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 kü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 sehen Sie die Grundstruktur eines redirects-Attributs. In diesem Beispiel werden Anfragen an /foo weitergeleitet, 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
  } ]
}

"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 von 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.

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.

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

"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 denselben Inhalt 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 dem angegebenen URL-Muster source oder regex entspricht, erhält der Browser stattdessen den Inhalt der Datei unter der URL destination.

Geben Sie URL-Überschreibungen an, indem Sie ein rewrites-Attribut erstellen, das ein Array von Objekten enthält (sogenannte „Überschreibregeln“). 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 sehen Sie die Grundstruktur eines rewrites-Attributs. 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"
  } ]
}

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

Firebase Hosting wendet nur dann eine Regel zum Überschreiben an, wenn eine Datei oder ein Verzeichnis nicht in einem URL-Pfad vorhanden ist, der mit dem angegebenen URL-Muster source oder regex ü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.

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

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

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

Überschreibungen von Hosting in 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 Datei firebase.json ist Folgendes erforderlich:

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 sehen Sie die Grundstruktur eines headers-Attributs. 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": "*"
    } ]
  } ]
}

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

Weitere Informationen zu Cache-Control finden Sie im Abschnitt Hosting, in dem die Bereitstellung von dynamischen Inhalten und das Hosten von Mikrodiensten beschrieben wird. Weitere Informationen zu CORS-Headern

.html-Erweiterungen verwalten

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

Bei true entfernt Hosting die .html-Erweiterung automatisch 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 Schlussstriche enthalten sollen.

• Wenn true, Hosting URLs weiterleitet, um einen abschließenden Schrägstrich hinzuzufügen.
• Wenn false, leitet Hosting URLs so weiter, dass der nachgestellte Schrägstrich entfernt wird.
• Wenn keine Angabe gemacht wird, 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

Firebase Hosting-Konfigurationsoptionen nutzen in großem Umfang die Notation für den glob-Musterabgleich mit extglob, ähnlich wie Git mit gitignore-Regeln und Bower ignore-Regeln verarbeitet. 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

• ** – Gleicht mit jeder Datei oder jedem Ordner in einem beliebigen Unterverzeichnis ab

• * – 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",

  }
}