Hosting-Verhalten konfigurieren

Mit Firebase Hosting können Sie benutzerdefiniertes 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 für Firebase Hosting bereitstellen möchten. Lernen wie.

  • Bereitstellen einer angepassten 404/Not Found-Seite. Lernen wie.

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

  • Richten Sie rewrites für einen dieser Zwecke:

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

    • Eine Funktion bereitstellen oder über eine Hosting-URL auf einen Cloud Run-Container zugreifen. Erfahren Sie, wie: Funktion oder Behälter .

    • Erstellen Sie einen benutzerdefinierten dynamischen Link für eine Domäne. Lernen wie.

  • In headers entlang Zusätzliche Informationen zu einem Antrag zu übergeben oder eine Antwort, wie , wie Browser die Seite und dessen Inhalt behandeln soll (Authentifizierung, Caching, Verschlüsselung, etc.). Lernen wie.

  • Richten Sie die Überarbeitung der Internationalisierung (i18n) ein, um bestimmte Inhalte basierend auf der Sprachpräferenz und/oder dem Land des Benutzers bereitzustellen. Erfahren Sie, wie (andere Seite).

Wo definieren Sie Ihre Hosting-Konfiguration?

Sie definieren Ihre Firebase Hosting - Konfiguration in Ihrer firebase.json Datei. Feuerbasis erstellt automatisch Ihre firebase.json Datei an der Wurzel des Projektverzeichnisses , wenn Sie den ausführen firebase init - Befehl.

Sie können einen finden volles firebase.json Konfigurationsbeispiel (für nur Firebase Hosting) am Ende der Seite. Beachten Sie, dass eine firebase.json Datei auch enthalten können Konfigurationen für andere Firebase Dienste .

Sie können die im Einsatz überprüfen firebase.json Inhalt der Verwendung von Hosting - REST - API .

Prioritätsreihenfolge der Hosting-Antworten

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

  1. Reservierte Namensräume , die mit einem Anfang /__/* Wegsegment
  2. konfiguriert Umleitungen
  3. Genau passender statischer Inhalt
  4. konfiguriert Neufassungen
  5. Benutzerdefinierte 404 - Seite
  6. Standard 404-Seite

Wenn Sie mit i18n umschreibt , die genau passenden und 404 Handhabung ist Prioritätsreihenfolge in ihrem Umfang erweitert Ihren „i18n Inhalt“ gerecht zu werden .

Geben Sie an, welche Dateien bereitgestellt werden sollen

Die Standardattribute - public und ignore - in der Standard enthielt firebase.json Datei , welche Dateien in Ihrem Projektverzeichnis definieren sollten Sie mit Ihrem Projekt Firebase eingesetzt werden.

Die Standard - hosting - Konfiguration in einer firebase.json Datei sieht wie folgt aus :

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

öffentlich

Erforderlich
Die public Attribut gibt an Firebase Hosting , welches Verzeichnis zu implementieren. Der Standardwert ist ein Verzeichnis mit dem Namen public , aber Sie können ein beliebiges Verzeichnis Pfad angeben, solange es in Ihrem Projektverzeichnis existiert.

Der folgende Standardname des bereitzustellenden Verzeichnisses ist:

"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 auf deploy zu ignorieren. Es kann dauern Klackse die gleiche Art und Weise , dass Git Griffe .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
  ]
}

Anpassen einer 404/Nicht gefunden-Seite

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

Erstellen Sie eine neue Datei in Ihrem Projekt public Verzeichnis , benennen Sie es 404.html , fügen Sie dann Ihre benutzerdefinierte 404 Not Found Inhalt in die Datei.

Hosting wird Firebase den Inhalt dieser benutzerdefinierten Anzeige 404.html Seite , wenn ein Browser eine Trigger 404 Not Found Fehler auf Ihrer Domain oder Subdomain.

Weiterleitungen konfigurieren

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

URL umleitet angeben , indem ein Erstellen redirects Attribut , das ein Array von Objekten enthält (genannt „Redirect rules“). Geben Sie in jeder Regel ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting veranlasst, mit einer Umleitung an die angegebene Ziel-URL zu antworten.

Hier ist die Grundstruktur für ein redirects Attribut. Dieses Beispiel Umleitungen Anfragen /foo durch eine neue Anfrage zu machen /bar .

"hosting": {
  // ...

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

Die redirects Attribut enthält eine Reihe von Umadressierungsregel, wobei jede Regel unterhalb der Felder in der Tabelle enthalten muss.

Firebase Hosting vergleicht die source oder regex Wert gegen alle URL - Pfade zu Beginn jeder Anfrage (bevor der Browser fest , ob eine Datei oder einen Ordner in diesem Pfad vorhanden ist ). Wenn eine Übereinstimmung gefunden wird, dann sendet die Firebase Hosting Ursprungsserver eine HTTPS - Antwort zum Umleiten erzählt den Browser eine neue Anforderung an dem zu machen , destination - URL.

Feld Beschreibung
redirects
source (empfohlen)
oder regex

Ein URL-Muster, das bei Übereinstimmung mit der ursprünglichen Anforderungs-URL Hosting veranlasst, die Weiterleitung anzuwenden

destination

Eine statische URL, an die der Browser eine neue Anfrage stellen soll

Diese URL kann ein relativer oder ein absoluter Pfad sein.

type

Der HTTPS-Antwortcode

  • Verwenden , um eine Art von 301 für ‚verschoben Dauerhaft‘
  • Verwenden Sie eine Art von 302 für 'Found' (Temporary Redirect)

URL-Segmente für Weiterleitungen erfassen

Optional
Manchmal könnten, müssen Sie Capture bestimmte Segmente einer URL - Muster der Redirect - Regel ( source oder regex - Wert), dann wieder verwenden , um diese Segmente in der Herrschaft destination

Überschreiben konfigurieren

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

Sie können auch Neufassungen verwenden , um Anwendungen zu unterstützen , die Verwendung HTML5 pushstate für die Navigation. Wenn ein Browser versucht , einen URL - Pfad zu öffnen, die die angegebenen Spiele source oder regex URL - Musters, wird der Browser den Inhalt der Datei an der angegebenen destination - URL statt.

Angeben URL neu schreibt , indem ein Erstellen rewrites Attribut , das ein Array von Objekten enthält ( „Rewrite - Regeln“ genannt). Geben Sie in jeder Regel ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting 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 dient index.html für Anfragen auf 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"
  } ]
}

Das rewrites Attribut enthält eine Reihe von Rewrite - Regeln, wobei jede Regel unterhalb der Felder in der Tabelle enthalten muss.

Firebase Hosting gilt nur eine Rewrite - Regel , wenn eine Datei oder ein Verzeichnis nicht zu einem URL - Pfad vorhanden ist , die die angegebene einstimmt source oder regex URL - Muster. Wenn eine Anforderung löst eine Rewrite - Regel, der Browser gibt den tatsächlichen Inhalt der angegebenen destination statt einer HTTP - Umleitung.

Feld Beschreibung
rewrites
source (empfohlen)
oder regex

Ein URL-Muster, das bei Übereinstimmung mit der ursprünglichen Anforderungs-URL das Hosting auslöst, die Umschreibung anzuwenden

destination

Eine lokale Datei, die vorhanden sein muss

Diese URL kann ein relativer oder ein absoluter Pfad sein.

Direkte Anfragen an eine Funktion

Sie können mit rewrites eine Funktion aus einer Firebase Hosting URL dienen. Das folgende Beispiel ist ein Auszug aus dient , dynamischen Inhalten Cloud - Funktionen verwenden .

Um zum Beispiel alle Anforderungen von der Seite zu lenken /bigben auf Ihrer Hosting - Website , die auszuführen bigben Funktion:

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben"
  } ]
}

Nach der Zugabe zu Firebase dieser Rewrite - Regel und den Einsatz von (unter Verwendung 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

  • Irgendwelche verbundenen benutzerdefinierte Domains :
    CUSTOM_DOMAIN /bigben

Werden die Anträge auf Funktionen Umleitung mit Hosting, unterstützt HTTP - Request - Methoden 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 mit rewrites eine Wolke Run Behälter aus einem Firebase Hosting URL zuzugreifen. Das folgende Beispiel ist ein Auszug aus dienen dynamische Inhalte mit Cloud - Run .

Um zum Beispiel alle Anforderungen von der Seite zu lenken /helloworld auf Ihrer Hosting - Website den Start und Ausführen einer auslösen helloworld Container - Instanz:

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

Nach der Zugabe zu Firebase dieser Rewrite - Regel und den Einsatz von (unter Verwendung von firebase deploy ), Ihre Behälter Bild ist über die folgenden URLs erreichbar:

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

  • Irgendwelche verbundenen benutzerdefinierte Domains :
    CUSTOM_DOMAIN /helloworld

Werden die Anträge auf Cloud - Run - Container Umleitung mit Hosting, unterstützt HTTP - Request - Methoden GET , POST , HEAD , PUT , DELETE , PATCH und OPTIONS . Andere Methoden wie REPORT oder PROFIND werden nicht unterstützt.

Derzeit können Sie Cloud Run-Rewrites 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

Sie können mit rewrites zu benutzerdefinierten Domain dynamische Verknüpfungen erstellen. Besuchen Sie die dynamischen Link Dokumentation für detaillierte Informationen über eine benutzerdefinierte Domain für dynamische Links einrichten .

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

Konfigurieren von dynamischen Verknüpfungen in Ihrer firebase.json Datei erfordert die folgende:

Feld Beschreibung
appAssociation

Muss eingestellt werden AUTO

  • Wenn Sie dieses Attribut nicht in der Konfiguration enthalten, die Standardeinstellung für appAssociation ist AUTO .
  • Durch dieses Attribut Einstellung AUTO , Hosting kann dynamisch generieren assetlinks.json und apple-app-site-association - Dateien , wenn sie aufgefordert sind.
rewrites
source

Ein Pfad, den Sie für dynamische Links verwenden möchten

Im Gegensatz zu Regeln, die Pfade zu URLs umschreiben, dürfen Umschreibregeln für dynamische Links keine regulären Ausdrücke enthalten.

dynamicLinks Muss eingestellt werden true

Kopfzeilen konfigurieren

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

Angeben , benutzerdefinierte, dateispezifischen Antwort - Headern durch eine Schaffung headers - Attribut, das ein Array von Header - Objekte enthält. Geben Sie in jedem Objekt ein URL-Muster an, das bei Übereinstimmung mit dem Anforderungs-URL-Pfad Hosting 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": "*"
    } ]
  } ]
}

Das headers - Attribut enthält eine Reihe von Definitionen, wobei jede Definition der 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 veranlasst, den benutzerdefinierten Header anzuwenden

Um einen Header zu erstellen gegen Ihren übereinstimmen benutzerdefinierten 404 - 404.html source regex Seite , verwenden 404.html als source oder regex Wert.

Array von (Teil-) headers

Die benutzerdefinierten Header, die Hosting auf den Anforderungspfad anwendet

Jeder Unter Header muss einen umfassen key und value (siehe nächsten zwei Zeilen).

key Der Name des Headers, zum Beispiel Cache-Control
value Der Wert für den Header, zB max-age=7200

Sie können mehr darüber erfahren , Cache-Control im Hosting - Abschnitt , die dynamischen Inhalte und Hosting Microservice beschreibt dienen. Sie können auch mehr darüber erfahren , CORS - Header.

Steuer .html Erweiterungen

Optional
Das cleanUrls Attribut können Sie steuern , ob oder ob nicht URLs sollten enthalten .html - Erweiterung.

Wenn true , fällt Hosting automatisch die .html Erweiterung von hochgeladenen Datei - URLs. Wenn eine .html - Erweiterung wird in der Anfrage hinzugefügt, führt eine Hosting 301 Umleitung auf den gleichen Weg , aber beseitigt die .html - Erweiterung.

Hier ist , wie die Aufnahme zu steuern .html in URLs durch ein einschließlich cleanUrls Attribut:

"hosting": {
  // ...

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

Kontrollieren Sie nachgestellte Schrägstriche

Optional
Das trailingSlash Attribut können Sie steuern , ob oder ob nicht statische Inhalte URLs sollten folgende Schrägstriche enthalten.

  • Wenn true , Hosting Umleitungen URLs Slash hinzuzufügen.
  • Wenn false , Hosting Umleitungen URLs Slash zu entfernen.
  • Wenn nicht spezifiziert, Hosting verwendet nur Schrägstriche für Verzeichnisindexdateien (zum Beispiel Hinter about/index.html ).

Hier ist , wie zu steuern Schrägstriche Hinter durch eine Zugabe von trailingSlash Attribut:

"hosting": {
  // ...

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

Das trailingSlash Attribut wirkt sich nicht auf Neufassungen auf dynamische Inhalte von Cloud - Funktionen oder Cloud - Run serviert.

Globmusterabgleich

Firebase Hosting Konfigurationsmöglichkeiten machen ausgiebig Gebrauch von der passenden glob Muster Notation mit extglob, ähnlich wie Git Griffe gitignore Regeln und Bower Griffe ignore Regeln. Diese Wiki - Seite ist ein detaillierteres Referenz, aber die folgenden sind Erklärungen von Beispielen auf dieser Seite verwendet:

  • firebase.json - Nur entspricht die firebase.json - Datei im Stammverzeichnis des public Verzeichnisses

  • ** - Spiele eine Datei oder einen Ordner in einem beliebigen Unterverzeichnis

  • * - nur Spiele Dateien und Ordner in der Wurzel des public Verzeichnisses

  • **/.* - Für jeden Datei Anfang an mit . ( in der Regel Dateien versteckt, wie im .git Ordner) in einem beliebigen Unterverzeichnis

  • **/node_modules/** - Spiele eine Datei oder einen Ordner in einem beliebigen Unterverzeichnis eines node_modules Ordner, die sich in einem beliebigen Unterverzeichnis des sein können public Verzeichnis

  • **/*.@(jpg|jpeg|gif|png) - Spiele eine beliebige Datei in einem beliebigen Unterverzeichnis , dass Enden mit genau einer der folgenden Optionen : .jpg , .jpeg , .gif oder .png

Beispiel für eine vollständige Hosting-Konfiguration

Hier finden Sie ein vollständiges firebase.json Konfigurationsbeispiel für Firebase Hosting. Beachten Sie, dass eine firebase.json Datei auch enthalten können Konfigurationen für andere Firebase Dienste .

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

  }
}