Avec Firebase Hosting, vous pouvez configurer un comportement d'hébergement personnalisé pour les requêtes envoyées à votre site.
Que pouvez-vous configurer pour Hosting ?
Spécifiez les fichiers de votre répertoire de projet local que vous souhaitez déployer dans Firebase Hosting. En savoir plus
Proposez une page d'erreur 404/introuvable personnalisée. En savoir plus
Configurez
redirects
pour les pages que vous avez déplacées ou supprimées. En savoir plusConfigurez
rewrites
pour l'une des raisons suivantes:Affichez le même contenu pour plusieurs URL. Découvrez comment.
Diffuser une fonction ou accéder à un conteneur Cloud Run à partir d'une URL Hosting Découvrez comment: fonction ou conteneur.
Créez un domaine personnalisé Dynamic Link. En savoir plus
Ajoutez
headers
pour transmettre des informations supplémentaires sur une requête ou une réponse, par exemple la manière dont les navigateurs doivent gérer la page et son contenu (authentification, mise en cache, codage, etc.). En savoir plusConfigurez des réécritures d'internationalisation (i18n) pour diffuser du contenu spécifique en fonction de la préférence linguistique et/ou du pays de l'utilisateur. Découvrez comment procéder (page différente).
Où définissez-vous votre configuration Hosting ?
Vous définissez votre configuration Firebase Hosting 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 trouverez un exemple de configuration firebase.json
complet (ne couvrant que Firebase Hosting) en 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 Hosting.
Ordre de priorité des réponses Hosting
Les différentes options de configuration Firebase Hosting décrites sur cette page peuvent parfois se chevaucher. En cas de conflit, Hosting détermine sa réponse en utilisant l'ordre de priorité suivant:
- Espaces de noms réservés commençant par un segment de chemin d'accès
/__/*
- Redirections configurées
- Contenu statique en correspondance exacte
- Réécritures configurées
- Page d'erreur 404 personnalisée
- Page d'erreur 404 par défaut
Si vous utilisez des réécritures pour la localisation, la portée de l'ordre de priorité de la correspondance exacte et de la gestion des erreurs 404 est étendue pour prendre en charge votre "contenu de localisation".
Spécifier 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 du répertoire de votre projet qui doivent être déployés dans votre projet Firebase.
La configuration hosting
par défaut dans un fichier firebase.json
se présente comme suit:
"hosting": {
"public": "public", // the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
publique
Obligatoire
L'attribut public
spécifie le répertoire dans lequel déployer Firebase Hosting. La valeur par défaut est un répertoire nommé public
, mais vous pouvez spécifier le chemin d'accès de n'importe quel répertoire, à condition qu'il existe dans le répertoire de votre projet.
Voici le nom par défaut spécifié pour le 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
Facultatif
L'attribut ignore
spécifie les fichiers à ignorer lors du déploiement. Il peut accepter des expressions génériques 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 d'erreur 404/Page introuvable
Facultatif
Vous pouvez diffuser une erreur 404 Not Found
personnalisée lorsqu'un utilisateur tente d'accéder à une page qui n'existe pas.
Créez un fichier dans le répertoire public
de votre projet, nommez-le 404.html
, puis ajoutez-y votre contenu 404 Not Found
personnalisé.
Firebase Hosting affiche 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
Facultatif
Utilisez une redirection d'URL pour éviter les liens brisés 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 redirects
contenant un tableau d'objets (appelés "règles de redirection"). Dans chaque règle, spécifiez un format d'URL qui, s'il correspond au chemin d'URL de la requête, déclenche Hosting pour qu'il réponde par une redirection vers l'URL de destination spécifiée.
Voici la structure de base d'un attribut redirects
. Cet exemple redirige les requêtes vers /foo
en envoyant une nouvelle requête à /bar
.
"hosting": {
// ...
// Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
"redirects": [ {
"source": "/foo",
"destination": "/bar",
"type": 301
} ]
}
Afficher un exemple plus détaillé d'un attribut redirects
"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
} ]
}
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 ne 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 HTTPS indiquant au navigateur d'effectuer une nouvelle requête à l'URL destination
.
Champ | Description | |
---|---|---|
redirects |
||
source (recommandé) ou regex
|
Format d'URL qui, s'il correspond à l'URL de la requête initiale, déclenche Hosting pour appliquer la redirection
|
|
destination |
URL statique à laquelle le navigateur doit envoyer une nouvelle requête Cette URL peut être un chemin d'accès relatif ou absolu. |
|
type |
Code de réponse HTTPS
|
Capturer des segments d'URL pour les redirections
Facultatif
Il peut arriver que vous deviez 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 destination
de la règle.
Capturer des segments d'URL lorsque vous utilisez des expressions régulières
Si vous utilisez un champ source
(c'est-à-dire que vous spécifiez un caractère générique pour votre format d'URL), vous pouvez capturer des segments en incluant un préfixe :
pour les identifier. Si vous devez également capturer le reste du chemin d'accès de l'URL après le segment, incluez un *
immédiatement après le segment. Exemple :
"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 } ] }
Capturer des segments d'URL lorsque vous utilisez des expressions régulières RE2
Si vous utilisez un champ regex
(c'est-à-dire que vous spécifiez une expression régulière RE2 pour votre modèle d'URL), vous pouvez capturer des segments à l'aide de groupes de capture RE2 nommés ou non. Les groupes de capture nommés peuvent être utilisés dans le champ destination
avec un préfixe :
, tandis que les groupes de capture non nommés peuvent être référencés par leur indice numérique dans la valeur regex
, à partir de 1. Exemple :
"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 } ] }
Configurer les réécritures
Facultatif
Utilisez une réécriture pour afficher le même contenu pour plusieurs URL. Les réécritures sont particulièrement utiles avec la mise en correspondance de formats, car vous pouvez accepter n'importe quelle URL correspondant au format et laisser le code côté client décider de ce qui doit être affiché.
Vous pouvez également utiliser les réécritures pour prendre en charge les applications qui utilisent pushState HTML5 pour la navigation. Lorsqu'un navigateur tente d'ouvrir un chemin d'URL correspondant au format d'URL source
ou regex
spécifié, le contenu du fichier à l'URL destination
lui est fourni à la place.
Spécifiez les réécritures d'URL en créant un attribut rewrites
contenant un tableau d'objets (appelés "règles de réécriture"). Dans chaque règle, spécifiez un format d'URL qui, s'il correspond au chemin d'URL de la requête, 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 d'un attribut rewrites
. Cet exemple sert index.html
pour les requêtes de fichiers ou de 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"
} ]
}
Afficher un exemple plus détaillé d'un attribut rewrites
"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" } ] }
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 n'applique une règle de réécriture que si un fichier ou un répertoire n'existe pas à un chemin d'URL correspondant au format d'URL source
ou regex
spécifié.
Lorsqu'une requête déclenche une règle de réécriture, le navigateur renvoie le contenu réel du fichier destination
spécifié au lieu d'une redirection HTTP.
Champ | Description | |
---|---|---|
rewrites |
||
source (recommandé) ou regex
|
Format d'URL qui, s'il correspond à l'URL de la requête initiale, déclenche Hosting pour appliquer la réécriture
|
|
destination |
Un fichier local qui doit exister Cette URL peut être un chemin d'accès relatif ou absolu. |
Envoyer des requêtes directes à une fonction
Vous pouvez utiliser rewrites
pour diffuser une fonction à partir d'une URL Firebase Hosting. 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
de votre site Hosting vers l'exécution de la fonction bigben
:
"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)
}
} ]
}
Fonctionnement de region
dans le bloc function
Si
region
est omis d'un blocfunction
de la configurationhosting.rewrites
, la CLI Firebase tente de détecter automatiquement la région à partir du code source de la fonction, qui, si elle n'est pas spécifiée, est définie par défaut surus-central1
. Si le code source de la fonction n'est pas disponible, la CLI tente de détecter la région à partir de la fonction déployée. Si la fonction se trouve dans plusieurs régions, la CLI exige queregion
soit spécifié dans la configurationhosting.rewrites
.
Fonctionnement de pinTag
dans le bloc function
La fonctionnalité
pinTag
n'est disponible que dans Cloud Functions for Firebase (2e génération). Grâce à cette fonctionnalité, vous pouvez vous assurer que chaque fonction de génération du contenu dynamique de votre site est synchronisée avec vos ressources Hosting statiques et votre configuration Hosting. De plus, cette fonctionnalité vous permet de prévisualiser vos réécritures de fonctions sur les canaux de prévisualisation Hosting.Si vous ajoutez
"pinTag": true
à un blocfunction
de la configurationhosting.rewrites
, la fonction "épinglée" sera déployée avec vos ressources et votre configuration Hosting statiques, même lors de l'exécution de. Si vous effectuez un rollback d'une version de votre site, la fonction "épinglée" est également annulée.
firebase deploy --only hosting Cette fonctionnalité s'appuie sur les tags Cloud Run, qui sont limités à 1 000 tags par service et 2 000 tags par région. Cela signifie qu'après des centaines de déploiements, les versions les plus anciennes d'un site peuvent cesser de fonctionner.
Après avoir ajouté cette règle de réécriture et déployé votre fonction sur Firebase (à l'aide de firebase deploy
), vous pouvez y accéder via les URL suivantes:
Vos sous-domaines Firebase:
PROJECT_ID.web.app/bigben
etPROJECT_ID.firebaseapp.com/bigben
Domaines personnalisés connectés:
CUSTOM_DOMAIN/bigben
Lorsque vous redirigez des requêtes vers des fonctions avec Hosting, les méthodes de requête HTTP compatibles sont GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
et OPTIONS
.
Les autres méthodes telles que REPORT
ou PROFIND
ne sont pas acceptées.
Requêtes directes vers un conteneur Cloud Run
Vous pouvez utiliser rewrites
pour accéder à un conteneur Cloud Run à partir d'une URL Firebase Hosting. L'exemple suivant est un extrait de l'affichage de contenu dynamique à l'aide de Cloud Run.
Par exemple, pour diriger toutes les requêtes de la page /helloworld
sur votre site Hosting afin de déclencher le démarrage et l'exécution d'une instance de 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)
}
} ]
}
Fonctionnement de pinTag
dans le bloc run
Grâce à cette fonctionnalité, vous pouvez vous assurer que la révision de votre service Cloud Run pour générer le contenu dynamique de votre site est synchronisée avec vos ressources Hosting statiques et votre configuration Hosting. De plus, cette fonctionnalité vous permet de prévisualiser vos réécritures en Cloud Run sur les canaux de prévisualisation Hosting.
Si vous ajoutez
"pinTag": true
à un blocrun
de la configurationhosting.rewrites
, vos ressources et votre configuration Hosting statiques seront épinglées à la dernière révision du service Cloud Run au moment du déploiement. Si vous annulez une version de votre site, la révision du service Cloud Run "épinglé" est également annulée.Cette fonctionnalité s'appuie sur les tags Cloud Run, qui sont limités à 1 000 tags par service et 2 000 tags par région. Cela signifie qu'après des centaines de déploiements, les versions les plus anciennes d'un site peuvent cesser de fonctionner.
Après avoir ajouté cette règle de réécriture et déployé l'image de votre conteneur sur Firebase (à l'aide de firebase deploy
), vous pouvez y accéder via les URL suivantes:
Vos sous-domaines Firebase:
PROJECT_ID.web.app/helloworld
etPROJECT_ID.firebaseapp.com/helloworld
Domaines personnalisés connectés:
CUSTOM_DOMAIN/helloworld
Lorsque vous redirigez des requêtes vers des conteneurs Cloud Run avec Hosting, les méthodes de requête HTTP acceptées sont GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
et OPTIONS
. Les autres méthodes telles que REPORT
ou PROFIND
ne sont pas compatibles.
Pour des performances optimales, colocatez votre service Cloud Run avec Hosting à l'aide des régions suivantes:
us-west1
us-central1
us-east1
europe-west1
asia-east1
Les réécritures vers Cloud Run à partir de Hosting sont acceptées dans les régions suivantes:
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
Créer un domaine personnalisé Dynamic Links
Vous pouvez utiliser rewrites
pour créer le domaine personnalisé Dynamic Links. Consultez la documentation Dynamic Links pour en savoir plus sur la configuration d'un domaine personnalisé pour Dynamic Links.
Utilisez votre domaine personnalisé uniquement pour 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 } ] }Spécifier les préfixes de chemin de domaine personnalisé à utiliser pour Dynamic Links
"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 } ] }
Pour configurer Dynamic Links dans votre fichier firebase.json
, vous devez disposer des éléments suivants:
Champ | Description | |
---|---|---|
appAssociation |
Doit être défini sur
|
|
rewrites |
||
source |
Chemin d'accès que vous souhaitez utiliser pour Dynamic Links Contrairement aux règles qui réécrivent les chemins d'accès en URL, les règles de réécriture pour Dynamic Links ne peuvent pas contenir d'expressions régulières. |
|
dynamicLinks |
Doit être défini sur true
|
Configurer les en-têtes
Facultatif
Les en-têtes permettent au client et au serveur de transmettre des informations supplémentaires avec une requête 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, y compris le contrôle des accès, l'authentification, la mise en cache et l'encodage.
Spécifiez des en-têtes de réponse personnalisés spécifiques au fichier en créant un attribut headers
contenant un tableau d'objets d'en-tête. Dans chaque objet, spécifiez un format d'URL qui, s'il correspond au chemin d'URL de la requête, 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 à 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": "*"
} ]
} ]
}
Afficher un exemple plus détaillé d'un attribut headers
"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" } ] } ] }
L'attribut headers
contient un tableau de définitions, où chaque définition doit inclure les champs du tableau ci-dessous.
Champ | Description | ||
---|---|---|---|
headers |
|||
source (recommandé) ou regex
|
Modèle d'URL qui, s'il correspond à l'URL de la requête initiale, déclenche Hosting pour appliquer l'en-tête personnalisé
Pour créer un en-tête à faire correspondre à votre page d'erreur 404 personnalisée, utilisez |
||
Tableau de (sous-)headers |
En-têtes personnalisés que Hosting applique au chemin de requête Chaque sous-en-tête doit inclure une paire |
||
key |
Nom de l'en-tête, par exemple Cache-Control |
||
value |
Valeur de l'en-tête, par exemple max-age=7200 |
Pour en savoir plus sur Cache-Control
, consultez la section Hosting 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ôler les extensions .html
Facultatif
L'attribut cleanUrls
vous permet de contrôler si les URL doivent inclure l'extension .html
.
Lorsque true
, Hosting supprime automatiquement l'extension .html
des URL des fichiers importés. Si une extension .html
est ajoutée à la requête, Hosting effectue une redirection 301
vers le même chemin, mais supprime l'extension .html
.
Pour contrôler l'inclusion de .html
dans les URL, incluez un attribut cleanUrls
:
"hosting": {
// ...
// Drops `.html` from uploaded URLs
"cleanUrls": true
}
Contrôler les barres obliques finales
Facultatif
L'attribut trailingSlash
vous permet de contrôler si les URL de contenu statique doivent inclure des barres obliques à la fin.
- Lorsque
true
, Hosting redirige les URL pour ajouter une barre oblique finale. - Lorsque
false
, Hosting redirige les URL pour supprimer une barre oblique finale. - Si elle n'est pas spécifiée, Hosting n'utilise les barres obliques finales que pour les fichiers d'index de répertoire (par exemple,
about/index.html
).
Pour contrôler les barres obliques finales en ajoutant un attribut trailingSlash
:
"hosting": {
// ...
// Removes trailing slashes from URLs
"trailingSlash": false
}
L'attribut trailingSlash
n'a aucune incidence sur les réécritures du contenu dynamique diffusé par Cloud Functions ou Cloud Run.
Mise en correspondance de formats glob
Les options de configuration Firebase Hosting utilisent largement la notation de mise en correspondance de modèles glob avec extglob, comme 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 sur les exemples utilisés sur cette page:
firebase.json
: ne correspond qu'au fichierfirebase.json
dans la racine du répertoirepublic
.**
: correspond à n'importe quel fichier ou dossier d'un sous-répertoire arbitraire.*
: ne correspond qu'aux fichiers et aux dossiers de la racine du répertoirepublic
.**/.*
: correspond à tous les fichiers commençant par.
(généralement des fichiers masqués, comme dans le dossier.git
) dans un sous-répertoire arbitraire.**/node_modules/**
: correspond à n'importe quel fichier ou dossier d'un sous-répertoire arbitraire d'un dossiernode_modules
, qui peut lui-même se trouver dans un sous-répertoire arbitraire du répertoirepublic
.**/*.@(jpg|jpeg|gif|png)
: correspond à tous les fichiers d'un sous-répertoire arbitraire se terminant par exactement l'un des éléments suivants :.jpg
,.jpeg
,.gif
ou.png
.
Exemple de configuration complète de Hosting
Voici un exemple de configuration firebase.json
complète 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",
}
}