Con Firebase Hosting, puoi configurare un comportamento di hosting personalizzato per le richieste al tuo sito.
Cosa puoi configurare per l'Hosting?
Specifica quali file nella directory del progetto locale desideri distribuire su Firebase Hosting. Impara come.
Pubblica una pagina 404/Non trovata personalizzata. Impara come.
Imposta
redirects
per le pagine che hai spostato o eliminato. Impara come.Imposta le
rewrites
per uno qualsiasi di questi scopi:Mostra lo stesso contenuto per più URL. Impara come.
Servi una funzione o accedi a un container Cloud Run da un URL di hosting. Scopri come: funzione o contenitore .
Crea un link dinamico del dominio personalizzato. Impara come.
Aggiungi
headers
per trasmettere informazioni aggiuntive su una richiesta o una risposta, ad esempio come i browser dovrebbero gestire la pagina e il suo contenuto (autenticazione, memorizzazione nella cache, codifica, ecc.). Impara come.Configurare l'internazionalizzazione (i18n) riscrive per fornire contenuti specifici in base alle preferenze della lingua e/o al paese dell'utente. Scopri come (pagina diversa).
Dove definisci la tua configurazione di Hosting?
Definisci la configurazione di Firebase Hosting nel tuo file firebase.json
. Firebase crea automaticamente il tuo file firebase.json
nella radice della directory del tuo progetto quando esegui il comando firebase init
.
Puoi trovare un esempio completo di configurazione firebase.json
(che copre solo Firebase Hosting) in fondo a questa pagina. Tieni presente che un file firebase.json
può contenere anche configurazioni per altri servizi Firebase .
Puoi controllare il contenuto firebase.json
distribuito utilizzando l' API REST di hosting .
Ordine di priorità delle risposte dell'Hosting
Le diverse opzioni di configurazione di Firebase Hosting descritte in questa pagina possono talvolta sovrapporsi. In caso di conflitto, Hosting determina la sua risposta utilizzando il seguente ordine di priorità:
- Spazi dei nomi riservati che iniziano con un segmento di percorso
/__/*
- Reindirizzamenti configurati
- Contenuto statico a corrispondenza esatta
- Riscritture configurate
- Pagina 404 personalizzata
- Pagina 404 predefinita
Se stai utilizzando le riscritture i18n , l'ordine di priorità di gestione della corrispondenza esatta e 404 viene ampliato per adattarsi al tuo "contenuto i18n".
Specifica quali file distribuire
Gli attributi predefiniti — public
e ignore
— inclusi nel file firebase.json
predefinito definiscono quali file nella directory del progetto devono essere distribuiti nel progetto Firebase.
La configurazione di hosting
predefinita in un file firebase.json
è simile alla seguente:
"hosting": {
"public": "public", // the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
pubblico
Necessario
L'attributo public
specifica quale directory distribuire su Firebase Hosting. Il valore predefinito è una directory denominata public
, ma puoi specificare il percorso di qualsiasi directory, purché esista nella directory del tuo progetto.
Di seguito è riportato il nome predefinito specificato della directory da distribuire:
"hosting": {
"public": "public"
// ...
}
È possibile modificare il valore predefinito nella directory che si desidera distribuire:
"hosting": {
"public": "dist/app"
// ...
}
ignorare
Opzionale
L'attributo ignore
specifica i file da ignorare durante la distribuzione. Può richiedere glob nello stesso modo in cui Git gestisce .gitignore
.
Di seguito sono riportati i valori predefiniti da ignorare per i file:
"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
]
}
Personalizza una pagina 404/Non trovato
Opzionale
Puoi pubblicare un errore 404 Not Found
personalizzato quando un utente tenta di accedere a una pagina che non esiste.
Crea un nuovo file nella directory public
del tuo progetto, 404.html
, quindi aggiungi il tuo contenuto 404 Not Found
personalizzato al file.
Firebase Hosting visualizzerà il contenuto di questa pagina 404.html
personalizzata se un browser attiva un errore 404 Not Found
sul tuo dominio o sottodominio.
Configura reindirizzamenti
Opzionale
Utilizza un reindirizzamento URL per evitare collegamenti interrotti se hai spostato una pagina o per abbreviare gli URL. Ad esempio, puoi reindirizzare un browser da example.com/team
a example.com/about.html
.
Specifica i reindirizzamenti URL creando un attributo di redirects
che contiene una matrice di oggetti (denominata "regole di reindirizzamento"). In ogni regola, specifica un pattern URL che, se abbinato al percorso dell'URL della richiesta, fa sì che l'hosting risponda con un reindirizzamento all'URL di destinazione specificato.
Ecco la struttura di base per un attributo di redirects
. Questo esempio reindirizza le richieste a /foo
effettuando una nuova richiesta a /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'attributo redirects
contiene una matrice di regole di reindirizzamento, in cui ogni regola deve includere i campi nella tabella seguente.
Firebase Hosting confronta il valore di source
o regex
con tutti i percorsi URL all'inizio di ogni richiesta (prima che il browser determini se esiste un file o una cartella in quel percorso). Se viene trovata una corrispondenza, il server di origine di Firebase Hosting invia una risposta di reindirizzamento HTTPS dicendo al browser di effettuare una nuova richiesta all'URL di destination
.
Campo | Descrizione | |
---|---|---|
redirects | ||
source (consigliata)o regex | Un pattern URL che, se abbinato all'URL della richiesta iniziale, fa sì che l'hosting applichi il reindirizzamento
| |
destination | Un URL statico in cui il browser deve effettuare una nuova richiesta Questo URL può essere un percorso relativo o assoluto. | |
type | Il codice di risposta HTTPS
|
Acquisisci segmenti URL per i reindirizzamenti
Opzionale
A volte, potrebbe essere necessario acquisire segmenti specifici del pattern URL di una regola di reindirizzamento (valore source
o regex
), quindi riutilizzare questi segmenti nel percorso di destination
della regola.
Se stai utilizzando un campo source
(ovvero, specificando un glob per il pattern URL), puoi acquisire segmenti includendo un prefisso :
per identificare il segmento. Se devi acquisire anche il percorso URL rimanente dopo il segmento, includi un *
immediatamente dopo il segmento. Per esempio:
"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 } ] }
Se stai utilizzando un campo regex
(ovvero, specificando un'espressione regolare RE2 per il pattern URL), puoi acquisire segmenti utilizzando gruppi di acquisizione RE2 denominati o senza nome. I gruppi di acquisizione con nome possono essere utilizzati nel campo di destination
con un prefisso :
, mentre i gruppi di acquisizione senza nome possono essere referenziati dal loro indice numerico nel valore regex
, indicizzato da 1. Ad esempio:
"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 } ] }
Configura riscritture
Opzionale
Usa una riscrittura per mostrare lo stesso contenuto per più URL. Le riscritture sono particolarmente utili con la corrispondenza dei modelli, poiché puoi accettare qualsiasi URL che corrisponda al modello e lasciare che il codice lato client decida cosa visualizzare.
Puoi anche utilizzare le riscritture per supportare le app che utilizzano pushState HTML5 per la navigazione. Quando un browser tenta di aprire un percorso URL che corrisponde al pattern URL di source
o regex
specificato, al browser verrà invece fornito il contenuto del file nell'URL di destination
.
Specificare le riscritture degli URL creando un attributo di rewrites
che contiene una matrice di oggetti (denominata "regole di riscrittura"). In ogni regola, specifica un pattern URL che, se abbinato al percorso dell'URL della richiesta, fa sì che l'hosting risponda come se al servizio fosse stato assegnato l'URL di destinazione specificato.
Ecco la struttura di base per un attributo di rewrites
. Questo esempio serve index.html
per le richieste a file o directory che non esistono.
"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'attributo rewrites
contiene una matrice di regole di riscrittura, in cui ogni regola deve includere i campi nella tabella seguente.
Firebase Hosting applica una regola di riscrittura solo se un file o una directory non esiste in un percorso URL che corrisponde al pattern URL di source
o regex
specificato. Quando una richiesta attiva una regola di riscrittura, il browser restituisce il contenuto effettivo del file di destination
specificato anziché un reindirizzamento HTTP.
Campo | Descrizione | |
---|---|---|
rewrites | ||
source (consigliata)o regex | Un pattern URL che, se abbinato all'URL della richiesta iniziale, fa sì che l'hosting applichi la riscrittura
| |
destination | Un file locale che deve esistere Questo URL può essere un percorso relativo o assoluto. |
Richieste dirette a una funzione
Puoi utilizzare le rewrites
per servire una funzione da un URL di hosting Firebase. L'esempio seguente è un estratto dal servizio di contenuto dinamico utilizzando Cloud Functions .
Ad esempio, per indirizzare tutte le richieste dalla pagina /bigben
sul tuo sito di Hosting per eseguire la funzione bigben
:
"hosting": {
// ...
// Directs all requests from the page `/bigben` to execute the `bigben` function
"rewrites": [ {
"source": "/bigben",
"function": "bigben"
} ]
}
Dopo aver aggiunto questa regola di riscrittura e aver eseguito il deployment su Firebase (usando firebase deploy
), la tua funzione è raggiungibile tramite i seguenti URL:
I tuoi sottodomini Firebase:
PROJECT_ID .web.app/bigben
ePROJECT_ID .firebaseapp.com/bigben
Eventuali domini personalizzati collegati:
CUSTOM_DOMAIN /bigben
Quando si reindirizzano le richieste a funzioni con Hosting, i metodi di richiesta HTTP supportati sono GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
e OPTIONS
. Altri metodi come REPORT
o PROFIND
non sono supportati.
Richieste dirette a un container Cloud Run
Puoi utilizzare le rewrites
per accedere a un container Cloud Run da un URL di hosting Firebase. L'esempio seguente è un estratto dal servizio di contenuto dinamico utilizzando Cloud Run .
Ad esempio, per indirizzare tutte le richieste dalla pagina /helloworld
sul tuo sito di hosting per attivare l'avvio e l'esecuzione di un'istanza del contenitore 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)
}
} ]
}
Dopo aver aggiunto questa regola di riscrittura e aver eseguito il deployment su Firebase (usando firebase deploy
), l'immagine del tuo container è raggiungibile tramite i seguenti URL:
I tuoi sottodomini Firebase:
PROJECT_ID .web.app/helloworld
ePROJECT_ID .firebaseapp.com/helloworld
Eventuali domini personalizzati collegati:
CUSTOM_DOMAIN /helloworld
Quando si reindirizzano le richieste ai contenitori Cloud Run con Hosting, i metodi di richiesta HTTP supportati sono GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
e OPTIONS
. Altri metodi come REPORT
o PROFIND
non sono supportati.
Attualmente, puoi utilizzare le riscritture di Cloud Run con l'hosting nelle seguenti regioni:
-
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
Crea link dinamici di dominio personalizzati
È possibile utilizzare le rewrites
per creare collegamenti dinamici di dominio personalizzati. Visita la documentazione sui collegamenti dinamici per informazioni dettagliate sulla configurazione di un dominio personalizzato per i collegamenti dinamici .
Usa il tuo dominio personalizzato solo per i link dinamici
"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 } ] }
Specifica i prefissi di percorso di dominio personalizzati da utilizzare per i collegamenti dinamici
"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 configurazione di collegamenti dinamici nel file firebase.json
richiede quanto segue:
Campo | Descrizione | |
---|---|---|
appAssociation | Deve essere impostato su
| |
rewrites | ||
source | Un percorso che desideri utilizzare per i collegamenti dinamici A differenza delle regole che riscrivono i percorsi degli URL, le regole di riscrittura per i collegamenti dinamici non possono contenere espressioni regolari. | |
dynamicLinks | Deve essere impostato su true |
Configura le intestazioni
Opzionale
Le intestazioni consentono al client e al server di trasmettere informazioni aggiuntive insieme a una richiesta o una risposta. Alcuni insiemi di intestazioni possono influenzare il modo in cui il browser gestisce la pagina e il relativo contenuto, inclusi il controllo dell'accesso, l'autenticazione, la memorizzazione nella cache e la codifica.
Specificare intestazioni di risposta personalizzate e specifiche del file creando un attributo di headers
che contiene una matrice di oggetti di intestazione. In ogni oggetto, specifica un pattern URL che, se abbinato al percorso dell'URL della richiesta, attiva l'hosting per applicare le intestazioni di risposta personalizzate specificate.
Ecco la struttura di base per un attributo headers
. Questo esempio applica un'intestazione CORS a tutti i file di font.
"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'attributo headers
contiene una matrice di definizioni, in cui ogni definizione deve includere i campi nella tabella seguente.
Campo | Descrizione | ||
---|---|---|---|
headers | |||
source (consigliata)o regex | Un pattern URL che, se abbinato all'URL della richiesta iniziale, fa sì che l'hosting applichi l'intestazione personalizzata
Per creare un'intestazione da abbinare alla tua pagina 404 personalizzata , usa | ||
matrice di (sotto) headers | Le intestazioni personalizzate che Hosting applica al percorso della richiesta Ogni sottointestazione deve includere una coppia | ||
key | Il nome dell'intestazione, ad esempio Cache-Control | ||
value | Il valore per l'intestazione, ad esempio max-age=7200 |
Puoi saperne di più su Cache-Control
nella sezione Hosting che descrive la fornitura di contenuto dinamico e l'hosting di microservizi. Puoi anche saperne di più sulle intestazioni CORS .
Controlla le estensioni .html
Opzionale
L'attributo cleanUrls
consente di controllare se gli URL devono includere o meno l'estensione .html
.
Se true
, Hosting elimina automaticamente l'estensione .html
dagli URL dei file caricati. Se nella richiesta viene aggiunta un'estensione .html
, Hosting esegue un reindirizzamento 301
allo stesso percorso ma elimina l'estensione .html
.
Ecco come controllare l'inclusione di .html
negli URL includendo un attributo cleanUrls
:
"hosting": {
// ...
// Drops `.html` from uploaded URLs
"cleanUrls": true
}
Controlla le barre finali
Opzionale
L'attributo trailingSlash
consente di controllare se gli URL di contenuto statico devono includere o meno barre finali.
- Se
true
, l'hosting reindirizza gli URL per aggiungere una barra finale. - Se
false
, Hosting reindirizza gli URL per rimuovere una barra finale. - Se non specificato, Hosting utilizza solo barre finali per i file di indice delle directory (ad esempio,
about/index.html
).
Ecco come controllare le barre finali aggiungendo un attributo trailingSlash
:
"hosting": {
// ...
// Removes trailing slashes from URLs
"trailingSlash": false
}
L'attributo trailingSlash
non influisce sulle riscritture nel contenuto dinamico servito da Cloud Functions o Cloud Run.
Corrispondenza del modello glob
Le opzioni di configurazione di Firebase Hosting fanno ampio uso della notazione di corrispondenza del modello glob con extglob, in modo simile a come Git gestisce le regole gitignore
e Bower gestisce le regole ignore
. Questa pagina wiki è un riferimento più dettagliato, ma le seguenti sono spiegazioni di esempi utilizzati in questa pagina:
firebase.json
— Corrisponde solo al filefirebase.json
nella radice della directorypublic
**
— Corrisponde a qualsiasi file o cartella in una sottodirectory arbitraria*
— Corrisponde solo a file e cartelle nella radice della directorypublic
**/.*
— Corrisponde a qualsiasi file che inizia con.
(di solito file nascosti, come nella cartella.git
) in una sottodirectory arbitraria**/node_modules/**
— Corrisponde a qualsiasi file o cartella in una sottodirectory arbitraria di una cartellanode_modules
, che può essere essa stessa in una sottodirectory arbitraria della directorypublic
**/*.@(jpg|jpeg|gif|png)
— Corrisponde a qualsiasi file in una sottodirectory arbitraria che termina esattamente con una delle seguenti:.jpg
,.jpeg
,.gif
o.png
Esempio di configurazione Hosting completo
Di seguito è riportato un esempio completo di configurazione firebase.json
per Firebase Hosting. Tieni presente che un file firebase.json
può contenere anche configurazioni per altri servizi 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",
}
}