Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Configurer le comportement d'hébergement

Avec Firebase Hosting, vous pouvez configurer un comportement d'hébergement personnalisé pour les demandes adressées à votre site.

Que pouvez-vous configurer pour l'hébergement ?

  • Spécifiez les fichiers de votre répertoire de projet local que vous souhaitez déployer sur Firebase Hosting. Apprendre.

  • Servir une page 404/Not Found personnalisée. Apprendre.

  • Mettre en place des redirects pour les pages que vous avez déplacé ou effacé. Apprendre.

  • Mettre en place rewrites pour ces fins:

    • Afficher le même contenu pour plusieurs URL. Apprendre.

    • Diffusez une fonction ou accédez à un conteneur Cloud Run à partir d'une URL d'hébergement. Apprenez comment: fonction ou conteneur .

    • Créez un lien dynamique de domaine personnalisé. Apprendre.

  • Ajouter les en- headers pour transmettre des informations supplémentaires au sujet d' une demande ou d' une réponse, comme la façon dont les navigateurs doivent gérer la page et son contenu (authentification, mise en cache, l' encodage, etc.). Apprendre.

  • Configurez des réécritures d'internationalisation (i18n) pour servir un contenu spécifique en fonction des préférences linguistiques et/ou du pays d'un utilisateur. Apprenez comment (autre page).

Où définissez-vous votre configuration d'hébergement ?

Vous définissez votre configuration d' hébergement Firebase dans votre firebase.json fichier. Firebase crée automatiquement votre firebase.json fichier à la racine de votre répertoire de projet lorsque vous exécutez l' firebase init commande.

Vous pouvez trouver un plein firebase.json exemple de configuration (couvrant uniquement l' hébergement Firebase) au bas de cette page. Notez qu'un firebase.json fichier peut également contenir des configurations pour d' autres services Firebase .

Vous pouvez vérifier le déploiement firebase.json contenu en utilisant l' hébergement API REST .

Ordre de priorité des réponses d'hébergement

Les différentes options de configuration de Firebase Hosting décrites sur cette page peuvent parfois se chevaucher. En cas de conflit, Hosting détermine sa réponse selon l'ordre de priorité suivant :

  1. Réservé namespaces commençant par un /__/* segment de chemin
  2. configuré réoriente
  3. Contenu statique correspondant exactement
  4. configuré réécritures
  5. 404 Page
  6. Page 404 par défaut

Si vous utilisez réécritures i18n , l'ordre de priorité de correspondance exacte et 404 sont une manipulation portée étendue pour répondre à votre « contenu i18n ».

Spécifier les fichiers à déployer

Par défaut , les attributs - public et ignore - inclus dans la valeur par défaut firebase.json fichier définir les fichiers dans votre répertoire de projet devrait être déployé à votre projet Firebase.

La valeur par défaut d' hosting configuration dans un firebase.json ressemble fichier comme ceci:

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

Publique

Obligatoire
Les public Précise d'attributs qui répertoire pour déployer à Firebase Hosting. La valeur par défaut est un répertoire nommé public , mais vous pouvez spécifier le chemin d'un répertoire, tant qu'il existe dans votre répertoire de projet.

Voici le nom spécifié par défaut du répertoire à déployer :

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

  // ...
}

Vous pouvez remplacer la valeur par défaut par le répertoire que vous souhaitez déployer :

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

  // ...
}

ignorer

Optionnel
L' ignore spécifie l' attribut les fichiers à ignorer le déploiement. Il peut prendre globs la même manière que Git poignées .gitignore .

Les valeurs par défaut des fichiers à ignorer sont les suivantes :

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

Personnaliser une page 404/Introuvable

Optionnel
Vous pouvez servir une coutume 404 Not Found erreur lorsqu'un utilisateur essaie d'accéder à une page qui n'existe pas.

Créez un nouveau fichier dans votre projet de public répertoire , nommez - 404.html , puis ajoutez votre commande 404 Not Found contenu dans le fichier.

Hébergement Firebase affichera le contenu de cette coutume 404.html page si un navigateur déclenche une 404 Not Found erreur sur votre domaine ou sous - domaine.

Configurer les redirections

Optionnel
Utilisez une redirection d'URL pour empêcher les liens rompus si vous avez déplacé une page ou pour raccourcir les URL. Par exemple, vous pouvez rediriger un navigateur de example.com/team à example.com/about.html .

Spécifiez redirections d'URL en créant une redirects attribut qui contient un tableau d'objets (appelés « règles de redirection »). Dans chaque règle, spécifiez un modèle d'URL qui, s'il correspond au chemin d'URL de la demande, déclenche la réponse de Hosting avec une redirection vers l'URL de destination spécifiée.

Voici la structure de base pour une redirects attribut. Cet exemple redirige les requêtes vers /foo en faisant une nouvelle demande au /bar .

"hosting": {
  // ...

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

L' redirects attribut contient une série de règles de redirection, où chaque règle doit inclure les champs dans le tableau ci - dessous.

Hébergement Firebase compare la source de ou regex valeur par rapport à tous les chemins d'URL au début de chaque demande (avant que le navigateur détermine si un fichier ou un dossier existe à ce chemin). Si une correspondance est trouvée, le serveur d'origine envoie hébergement Firebase une réponse HTTPS redirect indiquant le navigateur pour faire une nouvelle demande à la destination URL.

Champ La description
redirects
la source (recommandé)
ou regex

Un modèle d'URL qui, s'il correspond à l'URL de la demande initiale, déclenche l'application de la redirection par Hosting

destination

Une URL statique où le navigateur doit faire une nouvelle requête

Cette URL peut être un chemin relatif ou absolu.

type

Le code de réponse HTTPS

  • Utilisez un type de 301 pour « Déplacement définitif »
  • Utilisez un type de 302 pour 'Found' (Temporary Redirect)

Capturer des segments d'URL pour les redirections

Optionnel
Parfois, vous pourriez avoir besoin de segments spécifiques de capture d'un format d'URL de règle de redirection ( source ou regex valeur), puis ré-utiliser ces segments de la règle destination chemin.

Configurer les réécritures

Optionnel
Utilisez une réécriture pour afficher le même contenu pour plusieurs URL. Les réécritures sont particulièrement utiles avec la correspondance de modèle, car vous pouvez accepter n'importe quelle URL qui correspond au modèle et laisser le code côté client décider quoi afficher.

Vous pouvez également utiliser réécritures pour soutenir des applications qui utilisent HTML5 pushState pour la navigation. Quand une tentative de navigateur pour ouvrir un chemin d'URL qui correspond à l' endroit spécifié la source ou regex modèle d'URL, le navigateur sera donné le contenu du fichier à la destination URL au lieu.

Spécifier l' URL réécrit en créant un rewrites attribut qui contient un tableau d'objets (appelés « règles de réécriture »). Dans chaque règle, spécifiez un modèle d'URL qui, s'il correspond au chemin d'URL de la demande, déclenche la réponse de Hosting comme si le service avait reçu l'URL de destination spécifiée.

Voici la structure de base pour un rewrites attribut. Cet exemple sert index.html pour les demandes de fichiers ou des répertoires qui n'existent pas.

"hosting": {
  // ...

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

Le rewrites attribut contient un ensemble de règles de réécriture, où chaque règle doit inclure les champs dans le tableau ci - dessous.

Hébergement Firebase applique uniquement une règle de réécriture si un fichier ou un répertoire n'existe pas un chemin d'URL qui correspond à celle spécifiée la source ou regex modèle d'URL. Lorsqu'une demande déclenche une règle de réécriture, le retour du navigateur , le contenu réel de la spécifiée destination fichier au lieu d'une redirection HTTP.

Champ La description
rewrites
la source (recommandé)
ou regex

Un modèle d'URL qui, s'il correspond à l'URL de la demande initiale, déclenche l'application de la réécriture par Hosting

destination

Un fichier local qui doit exister

Cette URL peut être un chemin relatif ou absolu.

Demandes directes à une fonction

Vous pouvez utiliser rewrites pour remplir une fonction à partir d' une URL d' hébergement Firebase. L'exemple suivant est un extrait de service contenu dynamique à l' aide des fonctions de Cloud .

Par exemple, pour diriger toutes les demandes de la page /bigben sur votre site d' hébergement pour exécuter la bigben fonction:

"hosting": {
  // ...

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

Après avoir ajouté cette règle de réécriture et le déploiement à Firebase ( en utilisant firebase deploy ), votre fonction est accessible via les URL suivantes:

  • Vos sous-domaines Firebase :
    PROJECT_ID .web.app/bigben et PROJECT_ID .firebaseapp.com/bigben

  • Tous les connectés domaines personnalisés :
    CUSTOM_DOMAIN /bigben

Lors de la redirection des demandes de fonctions avec l' hébergement, les méthodes de requête HTTP pris en charge sont GET , POST , HEAD , PUT , DELETE , PATCH et OPTIONS . D' autres méthodes comme REPORT ou PROFIND ne sont pas pris en charge.

Requêtes directes vers un conteneur Cloud Run

Vous pouvez utiliser rewrites pour accéder à un conteneur nuage Exécuter à partir d' une URL d' hébergement Firebase. L'exemple suivant est un extrait de servir de contenu dynamique en utilisant Nuage Run .

Par exemple, pour diriger toutes les demandes de la page /helloworld pour déclencher le démarrage et le fonctionnement d'un sur votre site d' hébergement helloworld instance de conteneur:

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

Après avoir ajouté cette règle de réécriture et le déploiement à Firebase ( en utilisant firebase deploy ), l' image de votre conteneur est accessible via les URL suivantes:

  • Vos sous-domaines Firebase :
    PROJECT_ID .web.app/helloworld et PROJECT_ID .firebaseapp.com/helloworld

  • Tous les connectés domaines personnalisés :
    CUSTOM_DOMAIN /helloworld

Lors de la redirection des demandes à conteneurs - Cloud Run avec hébergement, méthodes de requêtes HTTP pris en charge sont GET , POST , HEAD , PUT , DELETE , PATCH et OPTIONS . D' autres méthodes comme REPORT ou PROFIND ne sont pas pris en charge.

Actuellement, vous pouvez utiliser les réécritures Cloud Run avec l'hébergement dans les régions suivantes :

  • 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

Vous pouvez utiliser rewrites pour créer domaine personnalisé Dynamic Links. Visitez la documentation des liens dynamiques pour des informations détaillées sur la mise en place d' un domaine personnalisé pour Dynamic Liens .

  • Utilisez votre domaine personnalisé uniquement pour Dynamic Liens

    "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
      } ]
    }
    
  • Spécifiez les préfixes de chemin de domaine personnalisés à utiliser pour les liens dynamiques

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

Configuration des liens dynamiques dans votre firebase.json fichier nécessite les éléments suivants:

Champ La description
appAssociation

Doit être réglé sur AUTO

  • Si vous ne pas inclure cet attribut dans votre configuration, la valeur par défaut pour appAssociation est AUTO .
  • En définissant cet attribut à AUTO , hébergement peut générer dynamiquement assetlinks.json et apple-app-site-association fichiers quand ils sont demandés.
rewrites
source

Un chemin que vous souhaitez utiliser pour les liens dynamiques

Contrairement aux règles qui réécrivent les chemins d'accès aux URL, les règles de réécriture pour les liens dynamiques ne peuvent pas contenir d'expressions régulières.

dynamicLinks Doit être réglé sur true

Configurer les en-têtes

Optionnel
Les en-têtes permettent au client et au serveur de transmettre des informations supplémentaires avec une demande ou une réponse. Certains ensembles d'en-têtes peuvent affecter la façon dont le navigateur gère la page et son contenu, notamment le contrôle d'accès, l'authentification, la mise en cache et l'encodage.

Précisez, les en- têtes de réponse spécifiques à un fichier en créant un en- headers attribut qui contient un tableau d'objets d' en- tête. Dans chaque objet, spécifiez un modèle d'URL qui, s'il correspond au chemin d'URL de la demande, déclenche l'application par Hosting des en-têtes de réponse personnalisés spécifiés.

Voici la structure de base pour un en- headers attribut. Cet exemple applique un en-tête CORS pour tous les fichiers de polices.

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

Les en- headers attribut contient un tableau de définitions, où chaque définition doit inclure les champs dans le tableau ci - dessous.

Champ La description
headers
la source (recommandé)
ou regex

Un modèle d'URL qui, s'il correspond à l'URL de la demande initiale, déclenche l'application de l'en-tête personnalisé par Hosting

Pour créer un en- tête pour correspondre contre votre page 404 , utilisez 404.html comme la source ou regex valeur.

gamme de (sous-) headers

Les en-têtes personnalisés que Hosting applique au chemin de la demande

Chaque sous- en- tête doit inclure une key et la valeur paire (voir les deux lignes suivantes).

key Le nom de l' en- tête, par exemple Cache-Control
value La valeur de l' en- tête, par exemple max-age=7200

Vous pouvez en savoir plus sur Cache-Control dans la section d' hébergement qui décrit le contenu de service dynamique et microservices hébergement. Vous pouvez également en savoir plus sur CORS têtes.

Contrôle .html extensions

Optionnel
Le cleanUrls attribut vous permet de contrôler si oui ou non les URL doivent inclure la .html l' extension.

Lorsque true , hébergement gouttes automatiquement la .html extension à partir des URL de fichiers téléchargés. Si une .html extension est ajoutée à la demande, d' hébergement effectue une 301 redirection vers le même chemin , mais élimine la .html l' extension.

Voici comment contrôler l'inclusion des .html dans les URL en incluant un cleanUrls attribut:

"hosting": {
  // ...

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

Contrôler les barres obliques

Optionnel
Le trailingSlash attribut vous permet de contrôler si les URL de contenu statique ou ne devraient pas inclure des barres obliques de fuite.

  • Lorsque true , l' hébergement URL redirections pour ajouter un slash.
  • Lorsque false , d' hébergement URL redirections pour supprimer un slash.
  • Lorsque non précisées, d' hébergement utilise uniquement des barres obliques de suivi pour les fichiers d'index de répertoire (par exemple, à about/index.html de about/index.html ).

Voici comment contrôler les barres obliques arrière en ajoutant un trailingSlash attribut:

"hosting": {
  // ...

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

Le trailingSlash attribut ne porte pas atteinte au contenu dynamique réécritures servi par des fonctions Cloud ou Nuage Exécuter.

Correspondance de modèle de globe

Firebase options de configuration d' hébergement font grand usage de la correspondance de gitignore ignore motif de glob notation avec extglob, semblable à la façon dont les poignées Git gitignore règles et Bower poignées ignore des règles. Cette page wiki est une référence plus détaillée, mais les éléments suivants sont des explications des exemples utilisés sur cette page:

  • firebase.json - correspond uniquement au firebase.json fichier à la racine du public annuaire

  • ** - Autorise tout fichier ou un dossier dans un sous-répertoire arbitraire

  • * - correspond uniquement à des fichiers et des dossiers à la racine du public annuaire

  • **/.* - Autorise tout début de fichier avec . (généralement des fichiers cachés, comme dans le .git dossier) dans un sous-répertoire arbitraire

  • **/node_modules/** - Autorise tout fichier ou un dossier dans un sous-répertoire arbitraire d'un node_modules dossier, qui peut être lui - même dans un sous-répertoire arbitraire du public répertoire

  • **/*.@(jpg|jpeg|gif|png) - Autorise tout fichier dans un sous-répertoire arbitraire qui se termine par exactement un des éléments suivants: .jpg , .jpeg , .gif ou .png

Exemple de configuration d'hébergement complet

Ce qui suit est un plein firebase.json exemple de configuration pour l' hébergement Firebase. Notez qu'un firebase.json fichier peut également contenir des configurations pour d' autres services Firebase .

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

  }
}