Avec Firebase Hosting, vous pouvez configurer un comportement d'hébergement personnalisé pour les requêtes adressées à votre site.
Que pouvez-vous configurer pour l'hébergement ?
Spécifiez les fichiers du répertoire de votre projet local que vous souhaitez déployer sur Firebase Hosting. Apprendre.
Servir une page 404/Not Found personnalisée. Apprendre.
Configurez
redirects
pour les pages que vous avez déplacées ou supprimées. Apprendre.Configurez
rewrites
à l’une de ces fins :Afficher le même contenu pour plusieurs URL. Apprendre.
Servir une fonction ou accéder à un conteneur Cloud Run à partir d'une URL d'hébergement. Découvrez comment : fonction ou conteneur .
Créez un lien dynamique de domaine personnalisé. Apprendre.
Ajoutez
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 d’un utilisateur. Découvrez comment (page différente).
Où définissez-vous votre configuration d'hébergement ?
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 pouvez trouver un exemple de configuration complet firebase.json
(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. 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
/__/*
- Redirections configurées
- Contenu statique correspondant exactement
- Réécritures configurées
- Page 404 personnalisée
- Page 404 par défaut
Si vous utilisez des réécritures i18n , la correspondance exacte et l'ordre de priorité de gestion 404 sont étendus pour s'adapter à votre "contenu i18n".
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 de votre répertoire de projet qui doivent être déployés sur votre projet Firebase.
La configuration 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
Requis
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 modifier la valeur par défaut du 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 prendre des globs 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
Facultatif
Vous pouvez générer 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
de 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
Facultatif
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 redirects
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 de l'URL de la demande, déclenche la réponse de l'hébergement 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 effectuant 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
} ]
}
"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 sur ce chemin). Si une correspondance est trouvée, le serveur d'origine de Firebase Hosting envoie une réponse de redirection HTTPS indiquant au navigateur de faire une nouvelle requête à l'URL destination
.
Champ | Description | |
---|---|---|
redirects | ||
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 la redirection
| |
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
|
Capturez des segments d'URL pour les redirections
Facultatif
Parfois, vous devrez peut-être capturer des segments spécifiques du modèle d'URL d'une règle de redirection ( source
ou valeur regex
), puis réutiliser ces segments dans le chemin destination
de la règle.
Si vous utilisez un champ source
(c'est-à-dire en spécifiant un glob pour votre modèle d'URL), vous pouvez capturer des segments en incluant un préfixe :
pour identifier le segment. Si vous devez également capturer le chemin d'URL restant après le segment, incluez un *
immédiatement après le segment. Par 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 } ] }
Si vous utilisez un champ regex
(c'est-à-dire en spécifiant 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 sans nom peuvent être référencés par leur index numérique dans la valeur regex
, indexé à partir de 1. Par 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 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 quoi 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 recevra à la place le contenu du fichier à l'URL destination
.
Spécifiez les réécritures d'URL en créant un attribut 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 l'hébergement comme si le service recevait 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 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"
} ]
}
"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 applique une règle de réécriture uniquement si un fichier ou un répertoire n'existe pas sur un chemin d'URL qui correspond au modèle 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 | Un modèle d'URL qui, s'il correspond à l'URL de la demande initiale, déclenche l'hébergement pour appliquer la réécriture
| |
destination | Un fichier local qui doit exister Cette URL peut être un chemin relatif ou absolu. |
Requêtes directes vers une fonction
Vous pouvez utiliser rewrites
pour servir 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
de votre site d'hébergement 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)
}
} ]
}
Si
region
est omise dans 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, s'il n'est pas spécifié, est par défautus-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ée dans la configurationhosting.rewrites
.
La fonctionnalité
pinTag
est uniquement disponible dans Cloud Functions pour Firebase (2e génération). Avec cette fonctionnalité, vous pouvez vous assurer que chaque fonction de génération du contenu dynamique de votre site reste synchronisée avec vos ressources d'hébergement statiques et votre configuration d'hébergement. En outre, cette fonctionnalité vous permet de prévisualiser vos réécritures vers les fonctions sur les canaux de prévisualisation de l'hébergement.Si vous ajoutez
"pinTag": true
à un blocfunction
de la configurationhosting.rewrites
, alors la fonction "épinglée" sera déployée avec vos ressources d'hébergement statiques et votre configuration, même lors de l'exécution. Si vous restaurez une version de votre site, la fonction « épinglé » est également restaurée.
firebase deploy --only hosting Cette fonctionnalité s'appuie sur les balises Cloud Run , qui ont une limite de 1 000 balises par service et de 2 000 balises 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é sur Firebase (à l'aide firebase deploy
), votre fonction est accessible via les URL suivantes :
Vos sous-domaines Firebase :
PROJECT_ID .web.app/bigben
etPROJECT_ID .firebaseapp.com/bigben
Tous les domaines personnalisés connectés :
CUSTOM_DOMAIN /bigben
Lors de la redirection des requêtes vers des fonctions avec Hosting, les méthodes de requête HTTP prises en charge sont GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
et OPTIONS
. D'autres méthodes comme REPORT
ou PROFIND
ne sont pas prises en charge.
Requêtes directes vers un conteneur Cloud Run
Vous pouvez utiliser 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 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)
}
} ]
}
Avec 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 reste synchronisée avec vos ressources d'hébergement statiques et votre configuration d'hébergement. En outre, cette fonctionnalité vous permet de prévisualiser vos réécritures sur les canaux de prévisualisation Cloud Run on Hosting.
Si vous ajoutez
"pingTag": true
à un blocrun
de la configurationhosting.rewrites
, vos ressources d'hébergement statiques et votre configuration seront épinglées à la révision la plus récente du service Cloud Run, au moment du déploiement. Si vous restaurez une version de votre site, la révision du service Cloud Run « épinglé » est également restaurée.Cette fonctionnalité s'appuie sur les balises Cloud Run , qui ont une limite de 1 000 balises par service et de 2 000 balises 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é sur Firebase (à l'aide firebase deploy
), votre image de conteneur est accessible via les URL suivantes :
Vos sous-domaines Firebase :
PROJECT_ID .web.app/helloworld
etPROJECT_ID .firebaseapp.com/helloworld
Tous les domaines personnalisés connectés :
CUSTOM_DOMAIN /helloworld
Lors de la redirection des requêtes vers des conteneurs Cloud Run avec Hosting, les méthodes de requête HTTP prises en charge sont GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
et OPTIONS
. D'autres méthodes comme REPORT
ou PROFIND
ne sont pas prises en charge.
Pour de meilleures performances, colocalisez votre service Cloud Run avec l'hébergement en utilisant les régions suivantes :
-
us-west1
-
us-central1
-
us-east1
-
europe-west1
-
asia-east1
Les réécritures vers Cloud Run à partir de l'hébergement sont prises en charge 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 des liens dynamiques de domaine personnalisés
Vous pouvez utiliser rewrites
pour créer des liens dynamiques de domaine personnalisés. Consultez la documentation Dynamic Links pour obtenir des informations détaillées sur la configuration d'un domaine personnalisé pour Dynamic Links .
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écifier les préfixes de chemin de domaine personnalisés à 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 } ] }
La configuration des liens dynamiques dans votre fichier firebase.json
nécessite les éléments suivants :
Champ | Description | |
---|---|---|
appAssociation | Doit être réglé sur
| |
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 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 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 le codage.
Spécifiez des en-têtes de réponse personnalisés et spécifiques au fichier en créant un attribut headers
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 l'hébergement des 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": "*"
} ]
} ]
}
"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 | 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 | ||
tableau de (sous-)- 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 | 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ôler les extensions .html
Facultatif
L'attribut cleanUrls
vous permet de contrôler si les URL doivent inclure ou non l'extension .html
.
Lorsque 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ôler les barres obliques finales
Facultatif
L'attribut trailingSlash
vous permet de contrôler si les URL de contenu statique doivent inclure ou non des barres obliques finales.
- Lorsque
true
, Hosting redirige les URL pour ajouter une barre oblique finale. - Lorsque
false
, Hosting redirige les URL pour supprimer une barre oblique finale. - Lorsqu'il n'est pas spécifié, Hosting utilise uniquement des barres obliques finales pour les fichiers d'index de répertoire (par exemple,
about/index.html
).
Voici comment contrôler les barres obliques finales 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 servi par Cloud Functions ou Cloud Run.
Correspondance de modèle global
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 des exemples utilisés sur cette page :
firebase.json
— Correspond uniquement au fichierfirebase.json
à la racine du répertoirepublic
**
— Correspond à n'importe quel fichier ou dossier dans un sous-répertoire arbitraire*
— Correspond uniquement aux fichiers et dossiers à la racine du répertoirepublic
**/.*
— Correspond à n'importe quel 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 dossiernode_modules
, qui peut lui-même se trouver dans un sous-répertoire arbitraire du répertoirepublic
**/*.@(jpg|jpeg|gif|png)
— Correspond à n'importe quel fichier d'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
Ce qui suit est 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",
}
}