Hosting-Verhalten konfigurieren

Mit Firebase Hosting können Sie das Hostingverhalten für Anfragen an Ihre Website anpassen.

Was kann ich 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 („Nicht gefunden“) bereitstellen Weitere Informationen

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

• Richten Sie rewrites für einen der folgenden Zwecke ein:

  • Derselbe Inhalt wird für mehrere URLs angezeigt. Weitere Informationen

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

  • Benutzerdefinierte Domain erstellen Dynamic Link Weitere Informationen

• Fügen Sie headers hinzu, um zusätzliche Informationen zu einer Anfrage oder Antwort weiterzugeben, z. B. wie Browser die Seite und ihre Inhalte behandeln sollen (Authentifizierung, Caching, Codierung usw.). Weitere Informationen

• Richten Sie Internationalisierungs-Rewrites (i18n) ein, um bestimmte Inhalte basierend auf der Spracheinstellung und/oder dem Land eines Nutzers bereitzustellen. Weitere Informationen (andere Seite)

Wo definieren Sie die Hosting-Konfiguration?

Sie definieren die Firebase Hosting-Konfiguration in der Datei firebase.json. Firebase erstellt automatisch die Datei firebase.json 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ätenreihenfolge der Hosting-Antworten

Die verschiedenen Firebase Hosting-Konfigurationsoptionen, die auf dieser Seite beschrieben werden, können sich manchmal überschneiden. Bei einem Konflikt bestimmt Hosting die 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 Rewrites
5. Benutzerdefinierte 404-Seite
6. Standard-404-Fehlerseite

Wenn Sie i18n-Rewrites verwenden, wird die Prioritätsreihenfolge für die Verarbeitung von genauen Übereinstimmungen und 404-Fehlern erweitert, um Ihre „i18n-Inhalte“ zu berücksichtigen.

Festlegen, 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 Standardkonfiguration für hosting 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 welches Verzeichnis Firebase Hosting bereitgestellt werden soll. Der Standardwert ist das Verzeichnis public. Sie können jedoch einen beliebigen Verzeichnispfad angeben, sofern das Verzeichnis in Ihrem Projektverzeichnis vorhanden ist.

Im Folgenden finden Sie den standardmäßig angegebenen Namen des zu bereitstellenden 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 Attribut ignore gibt die Dateien an, die bei der Bereitstellung ignoriert werden sollen. Es kann Globs auf dieselbe Weise wie Git .gitignore verarbeiten.

Die Standardwerte für die zu ignorierenden Dateien sind:

"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 („Nicht gefunden“) anpassen

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

Erstellen Sie im Verzeichnis public Ihres Projekts eine neue Datei mit dem Namen 404.html und fügen Sie der Datei dann 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
Verwenden Sie eine URL-Weiterleitung, um defekte Links zu vermeiden, wenn Sie eine Seite verschoben haben, oder um URLs zu verkürzen. Sie können beispielsweise einen Browser von example.com/team zu example.com/about.html weiterleiten.

Geben Sie URL-Weiterleitungen an, indem Sie ein redirects-Attribut erstellen, das ein Array von Objekten (sogenannte „Weiterleitungsregeln“) enthält. Geben Sie in jeder Regel ein URL-Muster an, das, wenn es mit dem Anfrage-URL-Pfad übereinstimmt, Hosting veranlasst, mit einer Weiterleitung zur angegebenen Ziel-URL zu antworten.

Hier sehen Sie die grundlegende Struktur für ein redirects-Attribut. In diesem Beispiel werden Anfragen an /foo umgeleitet, 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
  } ]
}

"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 Tabelle unten enthalten muss.

Mit Firebase Hosting wird der Wert source oder regex mit allen URL-Pfaden am Anfang jeder Anfrage verglichen, bevor der Browser feststellt, ob an diesem Pfad eine Datei oder ein Ordner vorhanden ist. 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 einer Weiterleitungsregel (source- oder regex-Wert) erfassen und dann in der 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 dieselben Inhalte für mehrere URLs anzeigen. Rewrites sind besonders nützlich beim Musterabgleich, da Sie jede URL akzeptieren können, die dem Muster entspricht, und der clientseitige Code entscheidet, was angezeigt wird.

Sie können auch Rewrites 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 URL-Muster source oder regex übereinstimmt, erhält der Browser stattdessen den Inhalt der Datei unter der URL destination.

Geben Sie URL-Neuschreibungen an, indem Sie ein rewrites-Attribut erstellen, das ein Array von Objekten (sogenannte „Neuschreibungsregeln“) enthält. Geben Sie in jeder Regel ein URL-Muster an, das, wenn es mit dem URL-Pfad der Anfrage übereinstimmt, Hosting dazu veranlasst, so zu reagieren, als ob dem Dienst die angegebene Ziel-URL übergeben worden wäre.

Hier sehen Sie die grundlegende Struktur für ein rewrites-Attribut. In diesem Beispiel wird index.html für Anfragen an nicht vorhandene Dateien oder Verzeichnisse bereitgestellt.

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

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

Direkte Anfragen an eine Funktion

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

Wenn Sie beispielsweise alle Anfragen von der Seite /bigben auf Ihrer Hosting-Website an die Funktion bigben weiterleiten möchten, gehen Sie so vor:

"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 Rewrite-Regel 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 Domains:
  CUSTOM_DOMAIN/bigben

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

Direkte Anfragen an einen Cloud Run-Container

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

Wenn Sie beispielsweise alle Anfragen von der Seite /helloworld auf Ihrer Hosting-Website so weiterleiten möchten, dass das Starten und Ausführen einer helloworld-Containerinstanz ausgelöst wird:

"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 Rewrite-Regel 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 Domains:
  CUSTOM_DOMAIN/helloworld

Wenn Anfragen mit Hosting an Cloud Run-Container 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.

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

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

Das Umschreiben von Cloud Run in Hosting wird 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 „Dynamic Links“ erstellen

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.

• Benutzerdefinierte Domain nur für Dynamic Links verwenden

  "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 Pfadprä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
Mit Headern können Client und Server zusätzliche Informationen zusammen mit einer Anfrage oder Antwort übergeben. Einige Header können sich darauf auswirken, wie der Browser die Seite und ihre Inhalte verarbeitet, einschließlich Zugriffssteuerung, Authentifizierung, Caching und Codierung.

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

Hier sehen Sie die grundlegende Struktur 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": "*"
    } ]
  } ]
}

"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 Attribut headers enthält ein Array von Definitionen, wobei jede Definition die Felder in der Tabelle unten enthalten muss.

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

.html-Erweiterungen verwalten

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

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

So steuern Sie, ob .html in URLs enthalten ist, indem Sie ein cleanUrls-Attribut einfügen:

"hosting": {
  // ...

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

Nachgestellte Schrägstriche steuern

Optional
Mit dem Attribut trailingSlash können Sie festlegen, ob statische Inhalts-URLs nachgestellte Schrägstriche enthalten sollen.

• Wenn true, Hosting URLs weiterleitet, wird ein abschließender Schrägstrich hinzugefügt.
• Wenn false, leitet Hosting URLs weiter, um einen abschließenden Schrägstrich zu entfernen.
• Wenn nichts angegeben ist, verwendet Hosting nur nachgestellte Schrägstriche für Verzeichnisindexdateien (z. B. about/index.html).

So können Sie nachgestellte Schrägstriche mit dem Attribut trailingSlash steuern:

"hosting": {
  // ...

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

Das Attribut trailingSlash hat keine Auswirkungen auf das Umschreiben von dynamischen Inhalten, die von Cloud Functions oder Cloud Run bereitgestellt werden.

Glob-Musterabgleich

Bei den Firebase Hosting-Konfigurationsoptionen wird die Notation für Glob-Mustervergleich mit Extglob verwendet, ähnlich wie Git gitignore-Regeln und Bower ignore-Regeln verarbeitet. Diese Wiki-Seite enthält ausführlichere Informationen. Im Folgenden werden die Beispiele auf dieser Seite erläutert:

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

• **: Entspricht einer beliebigen Datei oder einem beliebigen Ordner in einem beliebigen Unterverzeichnis.

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

• **/.*: Entspricht jeder Datei, die mit . beginnt (in der Regel versteckte Dateien, wie im Ordner .git), in einem beliebigen Unterverzeichnis.

• **/node_modules/**: Entspricht einer beliebigen Datei oder einem beliebigen 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): Entspricht jeder Datei in einem beliebigen Unterverzeichnis, die mit genau einer der folgenden Endungen endet: .jpg, .jpeg, .gif oder .png.

Vollständiges Hosting-Konfigurationsbeispiel

Das Folgende ist ein vollständiges firebase.json-Konfigurationsbeispiel 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",

  }
}