Configura il comportamento dell'hosting

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.

• Fornire una pagina 404/Non trovato personalizzata. Impara come.

• Imposta redirects per le pagine che hai spostato o eliminato. Impara come.

• Imposta rewrites per uno qualsiasi di questi scopi:

  • Mostra lo stesso contenuto per più URL. Impara come.

  • Servi una funzione o accedi a un contenitore Cloud Run da un URL di hosting. Scopri come: funzione o contenitore .

  • Crea un collegamento dinamico di dominio personalizzato. Impara come.

• Aggiungi headers per trasmettere informazioni aggiuntive su una richiesta o una risposta, ad esempio il modo in cui i browser dovrebbero gestire la pagina e il suo contenuto (autenticazione, memorizzazione nella cache, codifica, ecc.). Impara come.

• Configura riscritture di internazionalizzazione (i18n) per offrire contenuti specifici in base alla preferenza linguistica e/o al paese dell'utente. Scopri come (pagina diversa).

Dove definisci la tua configurazione Hosting?

Definisci la configurazione del tuo hosting Firebase nel file firebase.json . Firebase crea automaticamente il file firebase.json nella radice della directory del progetto quando esegui il comando firebase init .

Attenzione: se esegui nuovamente firebase init e selezioni Hosting, il comando sovrascriverà la sezione hosting del file firebase.json riportandola alla configurazione predefinita.

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 a volte possono sovrapporsi. In caso di conflitto, Hosting determina la sua risposta utilizzando il seguente ordine di priorità:

1. Spazi dei nomi riservati che iniziano con un segmento di percorso /__/*
2. Reindirizzamenti configurati
3. Contenuto statico con corrispondenza esatta
4. Riscritture configurate
5. Pagina 404 personalizzata
6. Pagina 404 predefinita

Importante: all'interno di ciascuno degli attributi redirects e rewrites , Hosting applica il reindirizzamento o la riscrittura definita dalla prima regola con un modello URL che corrisponde al percorso richiesto. Pertanto, è necessario ordinare deliberatamente le regole all'interno di ciascuno degli attributi redirects e rewrites . redirects configurati hanno ancora la precedenza sulle rewrites .

Se utilizzi le riscritture i18n , l'ambito della corrispondenza esatta e dell'ordine di priorità di gestione 404 viene ampliato per accogliere il tuo "contenuto i18n".

Specificare 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 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 progetto.

Di seguito è riportato il nome predefinito specificato della directory da distribuire:

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

  // ...
}

Puoi modificare il valore predefinito della directory che desideri distribuire:

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

  // ...
}

ignorare

Opzionale
L'attributo ignore specifica i file da ignorare durante la distribuzione. Può accettare glob nello stesso modo in cui Git gestisce .gitignore .

Di seguito sono riportati i valori predefiniti per i file da ignorare:

"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 fornire un errore personalizzato 404 Not Found quando un utente tenta di accedere a una pagina che non esiste.

Crea un nuovo file nella directory public del tuo progetto, chiamalo 404.html , quindi aggiungi il contenuto personalizzato 404 Not Found 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, potresti reindirizzare un browser da example.com/team a example.com/about.html .

Specifica i reindirizzamenti URL creando un attributo redirects che contenga una serie di oggetti (chiamati "regole di reindirizzamento"). In ciascuna regola, specifica un modello URL che, se abbinato al percorso URL della richiesta, attiva Hosting per rispondere con un reindirizzamento all'URL di destinazione specificato.

Ecco la struttura di base per un attributo 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
  } ]
}

Visualizza un esempio più dettagliato per un attributo 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'attributo redirects contiene una serie di regole di reindirizzamento, in cui ciascuna regola deve includere i campi nella tabella seguente.

Firebase Hosting confronta il valore 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 Firebase Hosting invia una risposta di reindirizzamento HTTPS dicendo al browser di effettuare una nuova richiesta all'URL destination .

Campo		Descrizione
redirects
	source (consigliato) o regex	Un pattern URL che, se abbinato all'URL della richiesta iniziale, attiva Hosting per applicare il reindirizzamento Utilizza source per specificare un glob (consigliato) . Utilizza regex per specificare un'espressione regolare RE2 .
	destination	Un URL statico in cui il browser dovrebbe effettuare una nuova richiesta Questo URL può essere un percorso relativo o assoluto.
	type	Il codice di risposta HTTPS Utilizza il tipo 301 per "Spostato permanentemente" Utilizza un tipo 302 per "Trovato" (reindirizzamento temporaneo)

Importante: All'interno dell'attributo redirects , Hosting applica il reindirizzamento definito dalla prima regola con un modello URL che corrisponde al percorso richiesto. Pertanto, è necessario ordinare deliberatamente le regole all'interno dell'attributo redirects .

Cattura 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 destination della regola.

Cattura segmenti URL quando usi i glob

Se utilizzi 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
  } ]
}

Cattura segmenti URL quando utilizzi le espressioni regolari RE2

Se utilizzi 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 Capture denominati possono essere utilizzati nel campo destination con un prefisso : , mentre i gruppi Capture senza nome possono essere referenziati tramite il 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
Utilizza una riscrittura per mostrare lo stesso contenuto per più URL. Le riscritture sono particolarmente utili con la corrispondenza dei pattern, poiché puoi accettare qualsiasi URL che corrisponde al pattern e lasciare che sia il codice lato client a decidere 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 modello URL di source o regex specificato, al browser verrà invece fornito il contenuto del file nell'URL destination .

Specifica le riscritture URL creando un attributo rewrites che contiene una serie di oggetti (chiamati "regole di riscrittura"). In ciascuna regola, specifica un modello URL che, se abbinato al percorso URL della richiesta, fa sì che Hosting risponda come se al servizio fosse stato fornito l'URL di destinazione specificato.

Ecco la struttura di base per un attributo rewrites . Questo esempio serve index.html per 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"
  } ]
}

Visualizza un esempio più dettagliato per un attributo 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'attributo rewrites contiene una serie di regole di riscrittura, in cui ciascuna 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 source specificata o al modello URL regex . Quando una richiesta attiva una regola di riscrittura, il browser restituisce il contenuto effettivo del file destination specificato invece di un reindirizzamento HTTP.

Campo		Descrizione
rewrites
	source (consigliato) o regex	Un pattern URL che, se abbinato all'URL della richiesta iniziale, attiva Hosting per applicare la riscrittura Utilizza source per specificare un glob (consigliato) . Utilizza regex per specificare un'espressione regolare RE2 .
	destination	Un file locale che deve esistere Questo URL può essere un percorso relativo o assoluto.

Importante: all'interno dell'attributo rewrites , Hosting applica la riscrittura definita dalla prima regola con un modello URL che corrisponde al percorso richiesto. Quindi, è necessario ordinare deliberatamente le regole all'interno dell'attributo rewrites .

Richieste dirette a una funzione

Puoi utilizzare rewrites per svolgere una funzione da un URL di hosting Firebase. L'esempio seguente è un estratto della fornitura di contenuto dinamico utilizzando Cloud Functions .

Ad esempio, per indirizzare tutte le richieste dalla pagina /bigben sul tuo sito Hosting per eseguire la funzione 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)
    }
  } ]
}

Come funziona region all'interno del blocco function

Se region viene omessa da un blocco function della configurazione hosting.rewrites , la CLI Firebase tenta di rilevare automaticamente la regione dal codice sorgente della funzione che, se non specificato, per impostazione predefinita è us-central1 . Se il codice sorgente della funzione non è disponibile, la CLI tenta di rilevare la regione dalla funzione distribuita. Se la funzione si trova in più regioni, la CLI richiede che region sia specificata nella configurazione hosting.rewrites .

Come funziona pinTag all'interno del blocco function

La funzionalità pinTag è disponibile solo in Cloud Functions for Firebase (2a generazione). Con questa funzione, puoi garantire che ogni funzione per la generazione del contenuto dinamico del tuo sito sia mantenuta sincronizzata con le risorse di hosting statiche e la configurazione di hosting. Inoltre, questa funzionalità ti consente di visualizzare in anteprima le tue riscritture alle funzioni sui canali di anteprima dell'Hosting.

Se aggiungi "pinTag": true a un blocco function della configurazione hosting.rewrites , la funzione "pinned" verrà distribuita insieme alle risorse e alla configurazione di hosting statico, anche quando si esegue firebase deploy --only hosting . Se esegui il rollback di una versione del tuo sito, viene eseguito il rollback anche della funzione "bloccata".

Nota: se aggiungi un pinTag a una riscrittura esistente , devi prima distribuire la riscrittura aggiornata sul tuo canale "live". Dopo la distribuzione, puoi visualizzare in anteprima le modifiche al codice della tua funzione nei canali di anteprima dell'hosting senza influire sulla produzione.

Questa funzionalità si basa sui tag Cloud Run , che hanno un limite di 1000 tag per servizio e 2000 tag per regione. Ciò significa che dopo centinaia di implementazioni, le versioni più vecchie di un sito potrebbero smettere di funzionare.

Dopo aver aggiunto questa regola di riscrittura e aver effettuato la distribuzione su Firebase (utilizzando firebase deploy ), la tua funzione è raggiungibile tramite i seguenti URL:

• I tuoi sottodomini Firebase:
  PROJECT_ID .web.app/bigben e PROJECT_ID .firebaseapp.com/bigben

• Eventuali domini personalizzati collegati:
  CUSTOM_DOMAIN /bigben

Quando si reindirizzano le richieste alle 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 contenitore Cloud Run

Puoi utilizzare rewrites per accedere a un contenitore Cloud Run da un URL di hosting Firebase. L'esempio seguente è un estratto della fornitura 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)
   }
 } ]
}

Come funziona pinTag all'interno del blocco run

Con questa funzione, puoi garantire che la revisione del tuo servizio Cloud Run per la generazione del contenuto dinamico del tuo sito sia mantenuta sincronizzata con le risorse di hosting statiche e la configurazione di hosting. Inoltre, questa funzionalità ti consente di visualizzare in anteprima le tue riscritture sui canali di anteprima di Cloud Run on Hosting.

Se aggiungi "pingTag": true a un blocco run della configurazione hosting.rewrites , le risorse e la configurazione di hosting statiche verranno fissate alla revisione più recente del servizio Cloud Run, al momento della distribuzione. Se esegui il rollback di una versione del tuo sito, viene eseguito il rollback anche della revisione del servizio Cloud Run "bloccato".

Questa funzionalità si basa sui tag Cloud Run , che hanno un limite di 1000 tag per servizio e 2000 tag per regione. Ciò significa che dopo centinaia di implementazioni, le versioni più vecchie di un sito potrebbero smettere di funzionare.

Dopo aver aggiunto questa regola di riscrittura e aver eseguito la distribuzione su Firebase (utilizzando firebase deploy ), l'immagine del contenitore è raggiungibile tramite i seguenti URL:

• I tuoi sottodomini Firebase:
  PROJECT_ID .web.app/helloworld e PROJECT_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.

Per ottenere le migliori prestazioni, colloca il tuo servizio Cloud Run con l'hosting utilizzando le seguenti regioni:

• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

Le riscritture su Cloud Run dall'hosting sono supportate nelle seguenti regioni:

• 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

Crea collegamenti dinamici di dominio personalizzati

È possibile utilizzare rewrites per creare collegamenti dinamici di dominio personalizzati. Visita la documentazione di Dynamic Links per informazioni dettagliate sulla configurazione di un dominio personalizzato per Dynamic Links .

• Utilizza il tuo dominio personalizzato solo 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": "/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/"
      "dynamicLinks": true
    } ]
  }
  

• Specificare i prefissi del 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 dei collegamenti dinamici nel file firebase.json richiede quanto segue:

Campo		Descrizione
appAssociation		Deve essere impostato su AUTO Se non includi questo attributo nella configurazione, il valore predefinito per appAssociation è AUTO . Impostando questo attributo su AUTO , Hosting può generare dinamicamente file assetlinks.json e apple-app-site-association quando vengono richiesti.
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

Importante : per i collegamenti dinamici, prestare particolare attenzione all'ordine di priorità dell'hosting .

• Assicurati che il prefisso URL dei collegamenti dinamici non sia in conflitto con configurazioni di hosting con priorità più alta (ad esempio, il contenuto statico ospitato ha sempre la priorità sulle riscritture).
• All'interno di ciascuno degli attributi redirects e rewrites , Hosting applica il reindirizzamento o la riscrittura definita dalla prima regola con un modello URL che corrisponde al percorso richiesto. Pertanto, è necessario ordinare deliberatamente le regole all'interno di ciascuno degli attributi redirects e rewrites .

Per informazioni dettagliate, fare riferimento alla documentazione dei collegamenti dinamici .

Configura intestazioni

Opzionale
Le intestazioni consentono al client e al server di passare 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 suo contenuto, inclusi il controllo dell'accesso, l'autenticazione, la memorizzazione nella cache e la codifica.

Specifica intestazioni di risposta personalizzate e specifiche del file creando un attributo headers che contiene una serie di oggetti intestazione. In ogni oggetto, specifica un modello URL che, se abbinato al percorso URL della richiesta, attiva Hosting per applicare le intestazioni di risposta personalizzate specificate.

Ecco la struttura di base per un attributo headers . In questo esempio viene applicata un'intestazione CORS per tutti i file di caratteri.

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

Visualizza un esempio più dettagliato per un attributo 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'attributo headers contiene una serie di definizioni, in cui ciascuna definizione deve includere i campi nella tabella seguente.

Campo			Descrizione
headers
	source (consigliato) o regex		Un pattern URL che, se abbinato all'URL della richiesta iniziale, fa sì che Hosting applichi l'intestazione personalizzata Utilizza source per specificare un glob (consigliato) . Utilizza regex per specificare un'espressione regolare RE2 . Per creare un'intestazione da abbinare alla tua pagina 404 personalizzata , utilizza 404.html come source o valore regex .
	array di (sotto) headers		Le intestazioni personalizzate che Hosting applica al percorso della richiesta Ogni sottointestazione deve includere una coppia key - value (vedi le due righe successive).
		key	Il nome dell'intestazione, ad esempio Cache-Control
		value	Il valore per l'intestazione, ad esempio max-age=7200

Nota: la corrispondenza del modello URL per le intestazioni personalizzate viene eseguita prima dell'applicazione di qualsiasi regola di riscrittura .

Puoi trovare ulteriori informazioni su Cache-Control nella sezione Hosting che descrive la fornitura di contenuti dinamici e l'hosting di microservizi. Puoi anche saperne di più sulle intestazioni CORS .

Importante: Firebase Hosting sovrascrive la configurazione Strict-Transport-Security sui sottodomini di hosting predefiniti (come *.web.app ). Tuttavia, qualsiasi dominio personalizzato connesso servirà il valore configurato.

Controlla le estensioni .html

Opzionale
L'attributo cleanUrls ti 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 sullo 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 ti consente di controllare se gli URL di contenuto statico devono includere o meno barre finali.

• Se true , 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 le 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 sui contenuti dinamici serviti da Cloud Functions o Cloud Run.

Corrispondenza del modello globale

Le opzioni di configurazione di Firebase Hosting fanno ampio uso della notazione di corrispondenza del modello glob con extglob, in modo simile al modo in cui Git gestisce le regole gitignore e Bower gestisce le regole ignore . Questa pagina wiki è un riferimento più dettagliato, ma di seguito sono riportate le spiegazioni degli esempi utilizzati in questa pagina:

• firebase.json : corrisponde solo al file firebase.json nella radice della directory public

• ** : corrisponde a qualsiasi file o cartella in una sottodirectory arbitraria

• * : corrisponde solo a file e cartelle nella radice della directory public

• **/.* : corrisponde a qualsiasi file che inizia con . (solitamente file nascosti, come nella cartella .git ) in una sottodirectory arbitraria

• **/node_modules/** — Corrisponde a qualsiasi file o cartella in una sottodirectory arbitraria di una cartella node_modules , che a sua volta può trovarsi in una sottodirectory arbitraria della directory public

• **/*.@(jpg|jpeg|gif|png) — Trova qualsiasi file in una sottodirectory arbitraria che termina esattamente con uno dei seguenti: .jpg , .jpeg , .gif o .png

Esempio di configurazione Hosting completa

Di seguito è riportato un esempio di configurazione completa 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",

  }
}