Google is committed to advancing racial equity for Black communities. See how.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

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 personnalisée 404 / introuvable. Apprendre.

  • Configurez des redirects pour les pages que vous avez déplacées ou supprimées. Apprendre.

  • Configurez des rewrites à l'une de ces fins:

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

    • Servez 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.

  • Ajoutez des en- headers pour transmettre des informations supplémentaires sur une requête ou une réponse, telles que la manière dont les navigateurs doivent gérer la page et son contenu (authentification, mise en cache, encodage, etc.). Apprendre.

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

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

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

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

Vous pouvez vérifier le contenu firebase.json déployé à l'aide de l' API REST d'hébergement .

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. S'il y a un conflit, Hosting détermine sa réponse en utilisant l'ordre de priorité suivant:

  1. Espaces de noms réservés commençant par un segment de chemin /__/*
  2. Redirections configurées
  3. Contenu statique exact
  4. Réécritures configurées
  5. Page 404 personnalisée
  6. Page 404 par défaut

Si vous utilisez des réécritures i18n , l'ordre de priorité de la correspondance exacte et de la gestion 404 est étendu pour s'adapter à votre «contenu i18n».

Spécifiez les fichiers à déployer

Les attributs par défaut - public et ignore - inclus dans le fichier firebase.json par défaut définissent les fichiers de votre répertoire de projet qui doivent être déployés dans votre projet Firebase.

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

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

Publique

Obligatoire
L'attribut public spécifie le répertoire à déployer sur Firebase Hosting. La valeur par défaut est un répertoire nommé public , mais vous pouvez spécifier le chemin de n'importe quel répertoire, à condition qu'il existe dans le répertoire de votre 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'attribut ignore spécifie les fichiers à ignorer lors du déploiement. Cela peut prendre des globes de la même manière que Git gère .gitignore .

Voici les valeurs par défaut des fichiers à ignorer:

"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 envoyer une erreur 404 Not Found personnalisée lorsqu'un utilisateur tente d'accéder à une page qui n'existe pas.

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

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

Configurer les redirections

Optionnel
Utilisez une redirection d'URL pour éviter 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 vers example.com/about.html .

Spécifiez les redirections d'URL en créant un attribut de redirects contenant 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 de l'URL de la demande, déclenche la réponse de Hosting par une redirection vers l'URL de destination spécifiée.

Voici la structure de base d'un attribut de redirects . Cet exemple redirige les requêtes vers /foo en faisant une nouvelle requête vers /bar .

"hosting": {
  // ...

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

L'attribut redirects contient un tableau de règles de redirection, où chaque règle doit inclure les champs du tableau ci-dessous.

Firebase Hosting compare la valeur source ou regex à tous les chemins d'URL au début de chaque requête (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 Firebase Hosting envoie une réponse de redirection HTTP indiquant au navigateur de faire une nouvelle requête à l'URL de destination .

Champ La description
redirects
source (recommandé)
ou regex

Un modèle d'URL qui, s'il correspond à l'URL de la requête initiale, déclenche l'hébergement pour appliquer la redirection

destination

Une URL statique où le navigateur doit faire une nouvelle demande

Cette URL peut être un chemin relatif ou absolu.

type

Le code de réponse HTTP

  • Utilisez un type de 301 pour "Déplacé définitivement"
  • Utilisez un type de 302 pour «Trouvé» (redirection temporaire)

Capturez des segments d'URL pour les redirections

Optionnel
Parfois, vous devrez peut-être capturer des segments spécifiques du modèle d'URL d'une règle de redirection (valeur source ou regex ), puis réutiliser ces segments dans le chemin de destination la règle.

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èles, car vous pouvez accepter n'importe quelle URL qui correspond au modèle et laisser le code côté client décider de ce qu'il faut afficher.

Vous pouvez également utiliser des réécritures pour prendre en charge les applications qui utilisent HTML5 pushState pour la navigation. Lorsqu'un navigateur tente d'ouvrir un chemin d'URL qui correspond au modèle d'URL source ou regex spécifié, le navigateur reçoit à la place le contenu du fichier à l'URL de destination .

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

Voici la structure de base d'un attribut de rewrites . Cet exemple sert index.html pour les requêtes vers des 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"
  } ]
}

L'attribut rewrites contient un tableau de règles de réécriture, où chaque règle doit inclure les champs du tableau ci-dessous.

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

Champ La description
rewrites
source (recommandé)
ou regex

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

destination

Un fichier local qui doit exister

Cette URL peut être un chemin relatif ou absolu.

Requêtes directes à une fonction

Vous pouvez utiliser des rewrites pour exécuter une fonction à partir d'une URL d'hébergement Firebase. L'exemple suivant est un extrait de la diffusion de contenu dynamique à l'aide de Cloud Functions .

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

"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 déployé sur Firebase (à l'aide de 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 domaines personnalisés connectés:
    CUSTOM_DOMAIN /bigben

Requêtes directes vers un conteneur Cloud Run

Vous pouvez utiliser des rewrites pour accéder à un conteneur Cloud Run à partir d'une URL d'hébergement Firebase. L'exemple suivant est un extrait de la diffusion de contenu dynamique à l'aide de Cloud Run .

Par exemple, pour diriger toutes les requêtes de la page /helloworld sur votre site d'hébergement pour déclencher le démarrage et l'exécution d'une helloworld conteneur helloworld :

"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 déployé sur Firebase (à l'aide de 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 domaines personnalisés connectés:
    CUSTOM_DOMAIN /helloworld

Vous pouvez utiliser des rewrites pour créer des liens dynamiques de domaine personnalisés. Consultez la documentation des liens dynamiques pour obtenir des informations détaillées sur la configuration d'un domaine personnalisé pour les liens dynamiques .

  • Utilisez votre domaine personnalisé uniquement 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": "/**",  // 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
      } ]
    }
    

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

Champ La description
appAssociation

Doit être réglé sur AUTO

  • Si vous n'incluez pas cet attribut dans votre configuration, la valeur par défaut pour appAssociation est AUTO .
  • En définissant cet attribut sur AUTO , l'hébergement peut générer dynamiquement des assetlinks.json et apple-app-site-association lorsqu'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 des liens dynamiques ne peuvent pas contenir d'expressions régulières.

dynamicLinks Doit être défini 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 manière 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.

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

Voici la structure de base d'un attribut headers . 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": "*"
    } ]
  } ]
}

L'attribut headers contient un tableau de définitions, où chaque définition doit inclure les champs du tableau ci-dessous.

Champ La description
headers
source (recommandé)
ou regex

Un modèle d'URL qui, s'il correspond à l'URL de la demande initiale, déclenche l'hébergement pour appliquer l'en-tête personnalisé

Pour créer un en-tête correspondant à votre page 404 personnalisée , utilisez 404.html comme valeur source ou regex .

tableau de (sous-) en- headers

Les en-têtes personnalisés que l'hébergement applique au chemin de la demande

Chaque sous-en-tête doit inclure une paire key et value (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 Hébergement qui décrit la diffusion de contenu dynamique et l'hébergement de microservices. Vous pouvez également en savoir plus sur les en-têtes CORS .

Contrôle des extensions .html

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

Lorsque la valeur est true , l'hébergement supprime automatiquement l'extension .html des URL des fichiers téléchargés. Si une extension .html est ajoutée dans la requête, Hosting effectue une redirection 301 vers le même chemin mais élimine l'extension .html .

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

"hosting": {
  // ...

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

Contrôle des barres obliques de fin

Optionnel
L'attribut trailingSlash vous permet de contrôler si les URL de contenu statique doivent inclure ou non des barres obliques de fin.

  • Lorsqu'il est true , l'hébergement redirige les URL pour ajouter une barre oblique finale.
  • Lorsqu'il est false , Hosting redirige les URL pour supprimer une barre oblique finale.
  • Lorsqu'il n'est pas spécifié, Hosting n'utilise que des barres obliques de fin pour les fichiers d'index de répertoire (par exemple, about/index.html ).

Voici comment contrôler les barres obliques de fin en ajoutant un attribut trailingSlash :

"hosting": {
  // ...

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

L'attribut trailingSlash n'affecte pas les réécritures du contenu dynamique diffusé par Cloud Functions ou Cloud Run.

Correspondance de modèle Glob

Les options de configuration de Firebase Hosting utilisent largement la notation de correspondance de modèle glob avec extglob, de la même manière que Git gère les règles gitignore et Bower gère les règles ignore . Cette page wiki est une référence plus détaillée, mais voici des explications d'exemples utilisés sur cette page:

  • firebase.json - firebase.json uniquement au fichier firebase.json à la racine du répertoire public

  • ** - Correspond à n'importe quel fichier ou dossier dans un sous-répertoire arbitraire

  • * - Correspond uniquement aux fichiers et dossiers à la racine du répertoire public

  • **/.* - Correspond à tout fichier commençant par . (généralement des fichiers cachés, comme dans le dossier .git ) dans un sous-répertoire arbitraire

  • **/node_modules/** - Correspond à n'importe quel fichier ou dossier dans un sous-répertoire arbitraire d'un dossier node_modules , qui peut lui-même se trouver dans un sous-répertoire arbitraire du répertoire public

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

Exemple de configuration d'hébergement complet

Voici un exemple de configuration firebase.json complet pour Firebase Hosting. Notez qu'un fichier firebase.json 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",

  }
}