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 tuo progetto locale desideri distribuire su Firebase Hosting. Impara come.

  • Pubblica una pagina 404/Non trovata personalizzata. Impara come.

  • Impostare redirects per le pagine che hai spostato o cancellato. Impara come.

  • Impostare rewrites per ciascuno di tali scopi:

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

    • Svolgi una funzione o accedi a un contenitore Cloud Run da un URL di hosting. Ulteriori informazioni su come: la funzione o il contenitore .

    • Crea un link dinamico del dominio personalizzato. Impara come.

  • Aggiungere headers di passare lungo ulteriori informazioni su una richiesta o una risposta, ad esempio come i browser dovrebbero gestire la pagina e il suo contenuto (l'autenticazione, il caching, la codifica, etc.). Impara come.

  • Imposta le riscritture per l'internazionalizzazione (i18n) per offrire contenuti specifici in base alla preferenza della lingua e/o del paese dell'utente. Imparare (pagina diversa).

Dove definisci la tua configurazione di Hosting?

È possibile definire la configurazione Firebase Hosting nel firebase.json file. Firebase crea automaticamente il firebase.json file alla radice della directory del progetto quando si esegue il firebase init comando.

È possibile trovare una completa firebase.json esempio di configurazione (che copre solo Hosting Firebase) in fondo a questa pagina. Si noti che un firebase.json file può anche contenere configurazioni per altri servizi Firebase .

È possibile controllare il schierato firebase.json contenuto utilizzando l' hosting API REST .

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 sua risposta utilizzando il seguente ordine di priorità:

  1. Spazi dei nomi riservati che iniziano con una /__/* segmento di percorso
  2. configurati redirect
  3. Contenuto statico a corrispondenza esatta
  4. configurati riscritture
  5. 404 personalizzata pagina
  6. Pagina 404 predefinita

Se stai usando riscritture i18n , l'ordine di priorità corrispondenza esatta e 404 maneggevolezza sono espanse in ambito di ospitare il vostro "contenuti i18n".

Specifica quali file distribuire

Gli attributi di default - public e ignore - incluso nel predefinito firebase.json file di definire i file nella directory del progetto dovrebbe essere distribuito al progetto Firebase.

L'impostazione predefinita hosting di configurazione in un firebase.json file ha un aspetto come questo:

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

pubblico

necessario
I public specifica degli attributi quale directory di implementare a Firebase Hosting. Il valore di default è una directory chiamata public , ma è possibile specificare il percorso di qualsiasi directory, fintanto che esiste nella directory del progetto.

Quello che segue è il nome specificato di default della directory da distribuire:

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

  // ...
}

Puoi modificare il valore predefinito nella directory che desideri distribuire:

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

  // ...
}

ignorare

Opzionale
La ignore specifica degli attributi dei file per ignorare il deploy. Si può prendere gocce allo stesso modo che Git maniglie .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 trovata

Opzionale
Si può servire una consuetudine 404 Not Found errore quando un utente tenta di accedere a una pagina che non esiste.

Creare un nuovo file in del progetto public directory , nominarlo 404.html , quindi aggiungere la vostra abitudine 404 Not Found contenuto al file.

Firebase Hosting visualizzerà il contenuto di questa usanza 404.html pagina se un browser innesca un 404 Not Found errore 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, è possibile reindirizzare un browser da example.com/team a example.com/about.html .

Specificare reindirizzamenti URL creando un redirects attributo che contiene un array di oggetti (chiamati "regole di reindirizzamento"). In ogni regola, specifica un pattern URL che, se abbinato al percorso dell'URL della richiesta, fa sì che Hosting risponda con un reindirizzamento all'URL di destinazione specificato.

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

Il redirects attributo contiene una serie di regole di reindirizzamento, dove ogni regola deve includere i campi nella tabella qui sotto.

Hosting Firebase confronta la source o regex valore contro tutti i percorsi URL all'inizio di ogni richiesta (prima che il browser determina se esiste un file o una cartella a quel percorso). Se viene trovata una corrispondenza, allora il server di origine Hosting Firebase invia una risposta di reindirizzamento HTTPS dicendo al browser di fare una nuova richiesta presso la destination URL.

Campo Descrizione
redirects
source (raccomandato)
o regex

Un pattern URL che, se abbinato all'URL della richiesta iniziale, attiva l'hosting per applicare il reindirizzamento

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

  • Utilizzare un tipo di 301 per 'Spostato in modo permanente'
  • Utilizzare un tipo di 302 per 'trovato' (Temporary Redirect)

Cattura segmenti URL per reindirizzamenti

Opzionale
A volte, potrebbe essere necessario segmenti cattura specifiche di formato URL di una regola di reindirizzamento ( source o regex valore), poi ri-utilizzare questi segmenti nella regola di destination percorso.

Configura riscritture

Opzionale
Utilizza una riscrittura per mostrare lo stesso contenuto per più URL. Le riscritture sono particolarmente utili con il pattern matching, in quanto puoi accettare qualsiasi URL che corrisponda al pattern e lasciare che il codice lato client decida cosa visualizzare.

È inoltre possibile utilizzare riscrive per supportare applicazioni che utilizzano HTML5 pushState per la navigazione. Quando un browser tenta di aprire un percorso URL che corrisponde al specificata source o regex modello URL, il browser sarà dato il contenuto del file alla destination URL invece.

Specificare URL riscrive creando un rewrites attributo che contiene un array di oggetti (chiamati "regole di riscrittura"). In ogni regola, specificare un pattern URL che, se abbinato al percorso dell'URL della richiesta, fa sì che Hosting risponda come se al servizio fosse fornito l'URL di destinazione specificato.

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

Il rewrites attributo contiene una serie di regole di riscrittura, dove ogni regola deve includere i campi nella tabella qui sotto.

Firebase Hosting vale solo una regola di riscrittura se un file o una directory non esiste un percorso URL che corrisponde al specificato source o regex modello URL. Quando una richiesta attiva una regola di riscrittura, il browser restituisce il contenuto effettivo del specificata destination file invece di un reindirizzamento HTTP.

Campo Descrizione
rewrites
source (raccomandato)
o regex

Un pattern URL che, se abbinato all'URL della richiesta iniziale, attiva l'hosting per applicare la riscrittura

destination

Un file locale che deve esistere

Questo URL può essere un percorso relativo o assoluto.

Richieste dirette a una funzione

È possibile utilizzare rewrites per servire una funzione da un Hosting URL Firebase. L'esempio seguente è un estratto da servire contenuti dinamici utilizzando funzioni cloud .

Ad esempio, per indirizzare tutte le richieste dalla pagina /bigben sul tuo sito di hosting per eseguire la bigben funzione di:

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben"
  } ]
}

Dopo l'aggiunta di questa regola di riscrittura e la distribuzione di 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 collegati domini personalizzati :
    CUSTOM_DOMAIN /bigben

Quando reindirizzando le richieste alle funzioni con Hosting, supportati metodi di richiesta HTTP 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

È possibile utilizzare rewrites per accedere a un contenitore di cloud eseguito da un Hosting URL Firebase. L'esempio seguente è un estratto da servire contenuti dinamici utilizzando cloud Esegui .

Ad esempio, per indirizzare tutte le richieste dalla pagina /helloworld sul tuo sito di hosting per innescare l'avvio e l'esecuzione di un helloworld esempio container:

"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 l'aggiunta di questa regola di riscrittura e la distribuzione di Firebase (utilizzando firebase deploy ), l'immagine contenitore è raggiungibile tramite i seguenti URL:

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

  • Eventuali collegati domini personalizzati :
    CUSTOM_DOMAIN /helloworld

Quando reindirizzando le richieste ai contenitori cloud Run con Hosting, supportati metodi di richiesta HTTP sono GET , POST , HEAD , PUT , DELETE , PATCH , e OPTIONS . Altri metodi come REPORT o PROFIND non sono supportati.

Al momento, 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

È possibile utilizzare rewrites per creare dominio personalizzato dinamica Links. Visita la documentazione dinamica Link Per informazioni dettagliate sulla creazione di un dominio personalizzato per Dynamic Link .

  • Usa il tuo dominio personalizzato solo per Dynamic Link

    "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 del percorso del dominio personalizzato 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
      } ]
    }
    

Configurazione dinamica link nella tua firebase.json file richiede quanto segue:

Campo Descrizione
appAssociation

Deve essere impostato su AUTO

  • Se non si include questo attributo nella configurazione, il valore predefinito per appAssociation è AUTO .
  • Impostando questo attributo su AUTO , hosting può generare dinamicamente assetlinks.json e apple-app-site-association dei file quando sono richieste.
rewrites
source

Un percorso che si desidera utilizzare per Dynamic Links Dynamic

A differenza delle regole che riscrivono i percorsi negli URL, le regole di riscrittura per i collegamenti dinamici non possono contenere espressioni regolari.

dynamicLinks Deve essere impostato a 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 set 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.

Specificare personalizzato, intestazioni di risposta specifici file creando un headers attributo che contiene un array di oggetti di intestazione. In ogni oggetto, specifica un pattern URL che, se abbinato al percorso dell'URL della richiesta, attiva Hosting per applicare le intestazioni di risposta personalizzate specificate.

Ecco la struttura di base per headers attributo. Questo esempio applica 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": "*"
    } ]
  } ]
}

L' headers attributo contiene una serie di definizioni, in cui ogni definizione deve includere i campi nella tabella qui sotto.

Campo Descrizione
headers
source (raccomandato)
o regex

Un pattern URL che, se abbinato all'URL della richiesta iniziale, attiva l'hosting per applicare l'intestazione personalizzata

Per creare un'intestazione per abbinare contro la tua pagina 404 personalizzata , utilizzare 404.html come source o regex valore.

array di (sotto) headers

Le intestazioni personalizzate che Hosting applica al percorso della richiesta

Ogni sotto-intestazione deve includere una key e value coppia (vedi due righe successive).

key Il nome dell'intestazione, ad esempio Cache-Control
value Il valore per l'intestazione, per esempio max-age=7200

È possibile saperne di più su Cache-Control nella sezione Hosting che descrive servire contenuto dinamico e microservices hosting. Si può anche imparare di più su CORS intestazioni.

Controllo .html estensioni

Opzionale
Il cleanUrls attributo consente di controllare se gli URL dovrebbero includere l' .html estensione.

Quando true , Presentatore automaticamente gocce del .html estensione da URL file caricato. Se un .html estensione viene aggiunto nella richiesta, Hosting compie un 301 reindirizzamento nello stesso percorso, ma elimina la .html estensione.

Ecco come controllare l'inserimento di .html in URL includendo un cleanUrls attributi:

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

Controlla le barre finali

Opzionale
Il trailingSlash attributo consente di controllare o meno dei contenuti URL statici dovrebbero includere slash.

  • Quando true , Presentatore reindirizzamenti URL per aggiungere una barra.
  • Quando false , Hosting reindirizzamenti URL per rimuovere una barra.
  • Quando non specificato, Hosting barre solo usi finali per i file di indice directory (ad esempio, about/index.html ).

Ecco come controllare trailing slash con l'aggiunta di un trailingSlash attributi:

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

Il trailingSlash attributo non incide riscritture di contenuti dinamici servito da Funzioni Cloud o nuvola Esegui.

Corrispondenza del modello del globo

Firebase opzioni di configurazione di hosting fanno largo uso del pattern matching glob notazione con extglob, simile a come le maniglie di Git gitignore regole e Bower maniglie ignore regole. Questa pagina wiki è un riferimento più dettagliata, ma le seguenti sono le spiegazioni di esempi utilizzati in questa pagina:

  • firebase.json - corrisponde solo il firebase.json file nella directory principale del public directory

  • ** - Corrisponde a qualsiasi file o una cartella in una sotto-directory arbitraria

  • * - corrisponde solo i file e le cartelle nella root del public directory

  • **/.* - Corrisponde a qualsiasi principio di file con . (di solito nascosti i file, come nel .git cartella) in una sub-directory arbitraria

  • **/node_modules/** - Partite qualsiasi file o cartella in modo arbitrario sotto-directory di un node_modules cartella, che a sua volta può essere in modo arbitrario sotto-directory del public directory

  • **/*.@(jpg|jpeg|gif|png) - Corrisponde a qualsiasi file in un sub-directory arbitraria che termina con esattamente una delle seguenti opzioni: .jpg , .jpeg , .gif o .png

Esempio di configurazione completa dell'hosting

Quanto segue è un full firebase.json esempio di configurazione per Firebase Hosting. Si noti che un firebase.json file può anche contenere 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",

  }
}