Configura il comportamento di Hosting

Con Firebase Hosting, puoi configurare un comportamento di hosting personalizzato per le richieste al tuo sito.

Cosa puoi configurare per Hosting?

• Specifica i file nella directory del progetto locale in cui vuoi eseguire il deploymentFirebase Hosting. Scopri come.

• Mostra una pagina 404/Non trovata personalizzata. Scopri come.

• Configura redirects per le pagine che hai spostato o eliminato. Scopri come.

• Configura rewrites per uno dei seguenti scopi:

  • Mostra gli stessi contenuti per più URL. Scopri come.

  • Pubblica una funzione o accedi a un contenitore Cloud Run da un URL Hosting. Scopri come: funzione o container.

  • Crea un dominio personalizzato Dynamic Link. Scopri come.

• Aggiungi headers per trasmettere informazioni aggiuntive su una richiesta o su una risposta, ad esempio la modalità di gestione della pagina e dei relativi contenuti da parte dei browser (autenticazione, memorizzazione nella cache, codifica e così via). Scopri come.

• Configura le riscritture per l'internazionalizzazione (i18n) per pubblicare contenuti specifici in base alla lingua e/o al paese dell'utente. Scopri come (pagina diversa).

Dove definisci la configurazione Hosting?

La configurazione di Firebase Hosting viene definita nel file firebase.json. Firebase crea automaticamente il file firebase.json nella directory principale del progetto quando esegui il comando firebase init.

Attenzione: se esegui di nuovo firebase init e selezioni Hosting, il comando sovrascriverà la sezione hosting del file firebase.json con la configurazione predefinita.

Puoi trovare un esempio completo di configurazione di 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 i contenuti firebase.json di cui è stato eseguito il deployment utilizzando l'API REST Hosting.

Ordine di priorità delle risposte di Hosting

Le diverse opzioni di configurazione di Firebase Hosting descritte in questa pagina a volte possono sovrapporsi. In caso di conflitto, Hosting determina la risposta utilizzando il seguente ordine di priorità:

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

Importante: all'interno di ciascun attributo redirects e rewrites, Hosting applica il reindirizzamento o la riscrittura definito dalla prima regola con un pattern URL corrispondente al percorso richiesto. Pertanto, devi ordinare deliberatamente le regole all'interno di ciascuno degli attributi redirects e rewrites. I valori redirects configurati hanno comunque la precedenza su rewrites.

Se utilizzi le riscritture i18n, l'ordine di priorità per la gestione della corrispondenza esatta e degli errori 404 viene ampliato per adattarsi ai tuoi "contenuti i18n".

Specifica i file da implementare

Gli attributi predefiniti public e ignore inclusi nel file firebase.json predefinito definiscono i file nella directory del progetto da eseguire nel progetto Firebase.

La configurazione predefinita di hosting in un file firebase.json è la seguente:

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

pubblica

Obbligatorio
L'attributo public specifica la directory in cui eseguire il deploymentFirebase 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 implementare:

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

  // ...
}

Puoi modificare il valore predefinito in base alla directory che vuoi eseguire il deployment:

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

  // ...
}

ignora

Facoltativo
L'attributo ignore specifica i file da ignorare durante il deployment. 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
  ]
}

Personalizzare una pagina 404/Pagina non trovata

Facoltativo
Puoi mostrare 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 progetto, chiamalo 404.html e poi aggiungi i contenuti 404 Not Found personalizzati al file.

Firebase Hosting mostrerà i contenuti di questa pagina 404.html personalizzata se un browser attiva un errore 404 Not Found sul tuo dominio o sottodominio.

Configurare i reindirizzamenti

Facoltativo
Utilizza un reindirizzamento URL per evitare link 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 di URL creando un attributo redirects contenente un array di oggetti (chiamati "regole di reindirizzamento"). In ogni regola, specifica un pattern URL che, se corrisponde al percorso dell'URL della richiesta, attiva Hosting per rispondere con un reindirizzamento all'URL di destinazione specificato.

Ecco la struttura di base di un attributo redirects. Questo esempio reindirizza le richieste a /foo inviando 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
  } ]
}

Visualizzare 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 un array di regole di reindirizzamento, in cui ogni regola deve includere i campi riportati 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 che indica al browser di effettuare una nuova richiesta all'URL destination.

Campo		Descrizione
redirects
	source (consigliato) oppure regex	Un pattern URL che, se corrisponde all'URL della richiesta iniziale, attiva Hosting per applicare il reindirizzamento Utilizza source per specificare un pattern (opzione consigliata). Utilizza regex per specificare un'espressione regolare RE2.
	destination	Un URL statico a cui il browser deve inviare una nuova richiesta Questo URL può essere un percorso relativo o assoluto.
	type	Il codice di risposta HTTPS Utilizza un tipo di 301 per "Trasferito definitivamente" Utilizza un tipo di 302 per "Risultato trovato" (Reindirizzamento temporaneo)

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

Acquisire i segmenti di URL per i reindirizzamenti

Facoltativo
A volte, potresti dover acquisire segmenti specifici del pattern URL (valore source o regex) di una regola di reindirizzamento, per poi riutilizzarli nel percorso destination della regola.

Acquisire i segmenti di URL quando si utilizzano i glob

Se utilizzi un campo source (ovvero specifichi un pattern per il pattern URL), puoi acquisire i segmenti includendo un prefisso : per identificarli. Se devi acquisire anche il percorso dell'URL rimanente dopo il segmento, includere un * subito dopo il segmento. Ad 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
  } ]
}

Acquisire i segmenti di URL quando si utilizzano le espressioni regolari RE2

Se utilizzi un campo regex (ovvero specifichi un'espressione regolare RE2 per il pattern dell'URL), puoi acquisire i segmenti utilizzando gruppi di cattura RE2 denominati o senza nome. I gruppi di cattura con nome possono essere utilizzati nel campo destination con un prefisso :, mentre i gruppi di cattura senza nome possono essere richiamati tramite il relativo 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
  } ]
}

Configurare le riscritture

Facoltativo
Utilizza una riscrittura per mostrare gli stessi contenuti per più URL. Le riscritture sono particolarmente utili con la corrispondenza dei pattern, in quanto 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 pattern URL source o regex specificato, al browser verranno forniti i contenuti del file all'URL destination.

Specifica le riscritture degli URL creando un attributo rewrites contenente un array di oggetti (chiamati "regole di riscrittura"). In ogni regola, specifica un pattern URL che, se corrisponde al percorso dell'URL della richiesta, attiva Hosting in modo che risponda come se al servizio fosse stato fornito l'URL di destinazione specificato.

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

Visualizzare 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 un array di regole di riscrittura, in cui ogni regola deve includere i campi riportati nella tabella seguente.

Firebase Hosting applica una regola di riscrittura solo se un file o una directory non esiste in un percorso dell'URL che corrisponde al pattern URL source o regex specificato. Quando una richiesta attiva una regola di riscrittura, il browser restituisce i contenuti effettivi del file destination specificato anziché un reindirizzamento HTTP.

Campo		Descrizione
rewrites
	source (consigliato) oppure regex	Un pattern URL che, se corrisponde all'URL della richiesta iniziale, attiva Hosting per applicare la riscrittura Utilizza source per specificare un pattern (opzione consigliata). 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 regola prima con un pattern URL che corrisponde al percorso richiesto. Pertanto, devi ordinare deliberatamente le regole all'interno dell'attributo rewrites.

Indirizzare le richieste a una funzione

Puoi utilizzare rewrites per eseguire una funzione da un URL Firebase Hosting. L'esempio seguente è un estratto della pubblicazione di contenuti dinamici utilizzando Cloud Functions.

Ad esempio, per indirizzare tutte le richieste dalla pagina /bigben sul tuo sito Hosting all'esecuzione della 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 omesso 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 specificata, ha come valore predefinito us-central1. Se il codice sorgente della funzione non è disponibile, la CLI tenta di rilevare la regione dalla funzione di cui è stato eseguito il deployment. Se la funzione si trova in più regioni, l'interfaccia a riga di comando richiede che region sia specificato nella configurazione hosting.rewrites.

Come funziona pinTag all'interno del blocco function

La funzionalità pinTag è disponibile solo su Cloud Functions for Firebase (2ª gen.). Con questa funzionalità, puoi assicurarti che ogni funzione per la generazione dei contenuti dinamici del tuo sito sia sincronizzata con le risorse Hosting statiche e la configurazione Hosting. Inoltre, ti consente di visualizzare l'anteprima delle funzioni di riscrittura sui canali di anteprima Hosting.

Se aggiungi "pinTag": true a un blocco function della configurazione hosting.rewrites, la funzione "bloccata" verrà dispiattata insieme alle risorse e alla configurazione Hosting statiche, anche durante l'esecuzione di 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 implementare la riscrittura aggiornata nel tuo canale "live". Dopo il deployment, puoi visualizzare l'anteprima delle modifiche al codice della funzione nei Hostingcanali di anteprima 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 deployment, le versioni più vecchie di un sito potrebbero smettere di funzionare.

Dopo aver aggiunto questa regola di riscrittura ed eseguito il deployment su Firebase (utilizzando firebase deploy), la 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 reindirizzi 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.

Indirizzare le richieste a un contenitore Cloud Run

Puoi utilizzare rewrites per accedere a un contenitore Cloud Run da un URL Firebase Hosting. L'esempio seguente è un estratto della pubblicazione di contenuti dinamici utilizzando Cloud Run.

Ad esempio, per indirizzare tutte le richieste dalla pagina /helloworld sul tuo sito Hosting in modo da attivare l'avvio e l'esecuzione di un'istanza di 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 funzionalità, puoi assicurarti che la revisione del servizio Cloud Run per la generazione dei contenuti dinamici del tuo sito sia sincronizzata con le risorse Hosting e la configurazione Hosting statiche. Inoltre, questa funzionalità ti consente di visualizzare l'anteprima delle riscritture in Cloud Run sui canali di anteprima Hosting.

Se aggiungi "pinTag": true a un blocco run della configurazione hosting.rewrites, le risorse e la configurazione Hosting statiche verranno bloccate alla revisione più recente del servizio Cloud Run al momento del deployment. 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 deployment, le versioni più vecchie di un sito potrebbero smettere di funzionare.

Dopo aver aggiunto questa regola di riscrittura ed eseguito il deployment 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 reindirizzi 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 il massimo rendimento, esegui la colocazione del servizio Cloud Run con Hosting utilizzando le seguenti regioni:

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

Le riscritture in Cloud Run da 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 un dominio personalizzato Dynamic Links

Puoi utilizzare rewrites per creare il dominio personalizzato Dynamic Links. Consulta la documentazione di Dynamic Links per informazioni dettagliate sulla configurazione di un dominio personalizzato per Dynamic Links.

• Utilizza il tuo dominio personalizzato solo per 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
    } ]
  }

• Specifica i prefissi dei percorsi dei domini personalizzati da utilizzare per 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 configurazione di Dynamic Links 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 i file assetlinks.json e apple-app-site-association quando vengono richiesti.
rewrites
	source	Un percorso che vuoi utilizzare per Dynamic Links A differenza delle regole che riscrivono i percorsi agli URL, le regole di riscrittura per Dynamic Links non possono contenere espressioni regolari.
	dynamicLinks	Deve essere impostato su true

Importante: per Dynamic Links, tieni particolarmente conto dell'ordine di priorità dell'hosting.

• Assicurati che il prefisso dell'URL Dynamic Links non entri in conflitto con configurazioni di hosting di priorità superiore (ad esempio, i contenuti statici ospitati hanno sempre la priorità sulle riscritture).
• All'interno di ciascuno degli attributi redirects e rewrites, Hosting applica il reindirizzamento o la riscrittura definito dalla prima regola con un pattern URL che corrisponde al percorso richiesto. Pertanto, devi ordinare deliberatamente le regole all'interno di ciascuno degli attributi redirects e rewrites.

Per informazioni dettagliate, consulta la documentazione di Dynamic Links.

Configurare le intestazioni

Facoltativo
Le intestazioni consentono al client e al server di trasmettere informazioni aggiuntive insieme a una richiesta o una risposta. Alcuni insiemi di intestazioni possono influire sul modo in cui il browser gestisce la pagina e i relativi contenuti, inclusi il controllo dell'accesso, l'autenticazione, la memorizzazione nella cache e la codifica.

Specifica intestazioni di risposta personalizzate e specifiche per file creando un attributo headers che contenga un array di oggetti intestazione. In ogni oggetto, specifica un pattern URL che, se corrisponde al percorso dell'URL della richiesta, attiva Hosting per applicare le intestazioni di risposta personalizzate specificate.

Ecco la struttura di base di un attributo headers. Questo esempio applica un'intestazione CORS per tutti i file dei 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": "*"
    } ]
  } ]
}

Visualizzare 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 un array di definizioni, in cui ogni definizione deve includere i campi riportati nella tabella seguente.

Campo			Descrizione
headers
	source (consigliato) oppure regex		Un pattern URL che, se corrisponde all'URL della richiesta iniziale, attiva Hosting per applicare l'intestazione personalizzata Utilizza source per specificare un pattern (opzione consigliata). Utilizza regex per specificare un'espressione regolare RE2. Per creare un'intestazione da associare alla pagina 404 personalizzata, utilizza 404.html come valore source o regex.
	array di (sub-)headers		Le intestazioni personalizzate applicate da Hosting al percorso della richiesta Ogni sottotitolo deve includere una coppia key e value (vedi le due righe successive).
		key	Il nome dell'intestazione, ad esempio Cache-Control
		value	Il valore dell'intestazione, ad esempio max-age=7200

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

Puoi scoprire di più su Cache-Control nella sezione Hosting che descrive la pubblicazione di contenuti dinamici e l'hosting di microservizi. Puoi anche scoprire di più sulle intestazioni CORS.

Importante: Firebase Hosting sovrascrive la configurazione di Strict-Transport-Security sui sottodomini Hosting predefiniti (ad esempio *.web.app). Tuttavia, tutti i domini personalizzati collegati pubblicheranno il valore configurato.

Controllare le estensioni .html

Facoltativo
L'attributo cleanUrls consente di controllare se gli URL devono includere o meno l'estensione .html.

Quando 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
}

Controllare le barre finali

Facoltativo
L'attributo trailingSlash consente di controllare se gli URL dei contenuti statici devono includere o meno le barre finali.

• Quando true, Hosting reindirizza gli URL in modo da aggiungere una barra finale.
• Quando false, Hosting reindirizza gli URL per rimuovere una barra finale.
• Se non specificato, Hosting utilizza le barre finali solo per i file indice 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 dei contenuti dinamici pubblicati da Cloud Functions o Cloud Run.

Corrispondenza di pattern glob

Le opzioni di configurazione di Firebase Hosting fanno ampio uso della notazione della corrispondenza dei pattern glob con extglob, in modo simile a come Git gestisce le regole gitignore e Bower gestisce le regole ignore. Questa pagina della 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 directory principale della directory public

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

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

• **/.*: 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 cartella node_modules, che può trovarsi a sua volta in una sottodirectory arbitraria della directory public

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

Esempio di configurazione completa di Hosting

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

  }
}