Firebase Hosting ile sitenize gelen istekler için özelleştirilmiş barındırma davranışını yapılandırabilirsiniz.
Hosting için neyi yapılandırabilirsiniz?
Yerel proje dizininizdeki hangi dosyaları Firebase Hosting'e dağıtmak istediğinizi belirtin. Nasıl öğrenilir.
Özelleştirilmiş bir 404/Bulunamadı sayfası sunun. Nasıl öğrenilir.
Taşıdığınız veya sildiğiniz sayfalar için
redirects
ayarlayın. Nasıl öğrenilir.rewrites
şu amaçlardan herhangi biri için ayarlayın:Birden fazla URL için aynı içeriği gösterin. Nasıl öğrenilir.
Bir Barındırma URL'sinden bir işlev sunun veya bir Cloud Run kapsayıcısına erişin. Nasıl yapılacağını öğrenin: işlev veya kapsayıcı .
Özel bir etki alanı Dinamik Bağlantısı oluşturun. Nasıl öğrenilir.
Tarayıcıların sayfayı ve içeriğini nasıl ele alması gerektiği (kimlik doğrulama, önbelleğe alma, kodlama vb.) gibi bir istek veya yanıtla ilgili ek bilgileri iletmek için
headers
ekleyin. Nasıl öğrenilir.Kullanıcının dil tercihine ve/veya ülkesine göre belirli içerik sunmak için uluslararasılaştırma (i18n) yeniden yazmalarını ayarlayın. Nasıl yapılacağını öğrenin (farklı sayfa).
Hosting yapılandırmanızı nerede tanımlarsınız?
Firebase Hosting yapılandırmanızı firebase.json
dosyanızda tanımlarsınız. Firebase, firebase init
komutunu çalıştırdığınızda, firebase.json
dosyanızı proje dizininizin kökünde otomatik olarak oluşturur.
firebase.json
yapılandırmasının tamamını (yalnızca Firebase Hosting'i kapsayan) bu sayfanın alt kısmında bulabilirsiniz. firebase.json
dosyasının diğer Firebase hizmetlerine ilişkin yapılandırmaları da içerebileceğini unutmayın.
Dağıtılan firebase.json
içeriğini Hosting REST API'sini kullanarak kontrol edebilirsiniz.
Barındırma yanıtlarının öncelik sırası
Bu sayfada açıklanan farklı Firebase Barındırma yapılandırma seçenekleri bazen çakışabilir. Bir çakışma olması durumunda Hosting, aşağıdaki öncelik sırasını kullanarak yanıtını belirler:
-
/__/*
yol bölümüyle başlayan ayrılmış ad alanları - Yapılandırılmış yönlendirmeler
- Tam eşleşen statik içerik
- Yapılandırılmış yeniden yazmalar
- Özel 404 sayfası
- Varsayılan 404 sayfası
i18n yeniden yazmalarını kullanıyorsanız, tam eşleşme ve 404 işleme öncelik sırası, "i18n içeriğinize" uyum sağlayacak şekilde genişletilir.
Hangi dosyaların dağıtılacağını belirtin
Varsayılan firebase.json
dosyasında bulunan varsayılan özellikler ( public
ve ignore
), proje dizininizdeki hangi dosyaların Firebase projenize dağıtılması gerektiğini tanımlar.
firebase.json
dosyasındaki varsayılan hosting
yapılandırması şuna benzer:
"hosting": {
"public": "public", // the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
halk
Gerekli
public
özelliği, Firebase Hosting'e hangi dizinin dağıtılacağını belirtir. Varsayılan değer public
adında bir dizindir, ancak proje dizininizde mevcut olduğu sürece herhangi bir dizinin yolunu belirtebilirsiniz.
Dağıtılacak dizinin varsayılan olarak belirtilen adı aşağıdadır:
"hosting": {
"public": "public"
// ...
}
Varsayılan değeri dağıtmak istediğiniz dizine değiştirebilirsiniz:
"hosting": {
"public": "dist/app"
// ...
}
görmezden gelmek
İsteğe bağlı
ignore
özelliği, dağıtım sırasında yoksayılacak dosyaları belirtir. Git'in .gitignore
işlediği şekilde globları alabilir.
Aşağıdakiler, dosyaların yoksayılacak varsayılan değerleridir:
"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
]
}
404/Bulunamadı sayfasını özelleştirme
İsteğe bağlı
Bir kullanıcı var olmayan bir sayfaya erişmeye çalıştığında özel bir 404 Not Found
hatası sunabilirsiniz.
Projenizin public
dizininde yeni bir dosya oluşturun, bunu 404.html
olarak adlandırın ve ardından özel 404 Not Found
içeriğinizi dosyaya ekleyin.
Bir tarayıcı alanınızda veya alt alan adınızda 404 Not Found
hatası tetiklediğinde Firebase Hosting bu özel 404.html
sayfasının içeriğini görüntüler.
Yönlendirmeleri yapılandırma
İsteğe bağlı
Bir sayfayı taşıdıysanız bağlantıların kopmasını önlemek veya URL'leri kısaltmak için URL yönlendirmesi kullanın. Örneğin, bir tarayıcıyı example.com/team
adresinden example.com/about.html
adresine yönlendirebilirsiniz.
Bir dizi nesne içeren bir redirects
özelliği ("yönlendirme kuralları" olarak adlandırılır) oluşturarak URL yönlendirmelerini belirtin. Her kuralda, istek URL yolu ile eşleştirildiğinde Hosting'in belirtilen hedef URL'ye bir yönlendirmeyle yanıt vermesini tetikleyecek bir URL modeli belirtin.
redirects
özelliğinin temel yapısı burada verilmiştir. Bu örnek, /bar
bar'a yeni bir istek yaparak istekleri /foo
yönlendirir.
"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
} ]
}
redirects
özelliği, her kuralın aşağıdaki tabloda yer alan alanları içermesi gereken bir dizi yönlendirme kuralı içerir.
Firebase Hosting, her isteğin başlangıcında source
veya regex
değerini tüm URL yollarıyla karşılaştırır (tarayıcı, o yolda bir dosya veya klasörün bulunup bulunmadığını belirlemeden önce). Bir eşleşme bulunursa Firebase Hosting kaynak sunucusu, tarayıcıya destination
URL'de yeni bir istekte bulunmasını bildiren bir HTTPS yönlendirme yanıtı gönderir.
Alan | Tanım | |
---|---|---|
redirects | ||
source (önerilir)veya regex | İlk istek URL'siyle eşleştirildiğinde Hosting'in yönlendirmeyi uygulamasını tetikleyen bir URL modeli
| |
destination | Tarayıcının yeni bir istekte bulunması gereken statik URL Bu URL göreceli veya mutlak bir yol olabilir. | |
type | HTTPS yanıt kodu
|
Yönlendirmeler için URL segmentlerini yakalayın
İsteğe bağlı
Bazen, bir yönlendirme kuralının URL modelinin belirli bölümlerini ( source
veya regex
değeri) yakalamanız ve ardından bu bölümleri kuralın destination
yolunda yeniden kullanmanız gerekebilir.
Bir source
alanı kullanıyorsanız (yani, URL modeliniz için bir küre belirtiyorsanız), segmenti tanımlamak için bir :
öneki ekleyerek segmentleri yakalayabilirsiniz. Segmentten sonra kalan URL yolunu da yakalamanız gerekiyorsa, segmentin hemen sonrasına bir *
ekleyin. Örneğin:
"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 } ] }
Bir regex
alanı kullanıyorsanız (yani, URL modeliniz için bir RE2 normal ifadesi belirtiyorsanız), adlandırılmış veya adsız RE2 yakalama gruplarını kullanarak segmentleri yakalayabilirsiniz. Adlandırılmış yakalama grupları, destination
alanda :
önekiyle kullanılabilirken, adsız yakalama gruplarına, 1'den dizine alınmış regex
değerindeki sayısal dizinleri ile başvurulabilir. Örneğin:
"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 } ] }
Yeniden yazma işlemlerini yapılandırma
İsteğe bağlı
Birden çok URL için aynı içeriği göstermek amacıyla yeniden yazma özelliğini kullanın. Yeniden yazmalar özellikle kalıp eşleştirmede kullanışlıdır; çünkü kalıpla eşleşen herhangi bir URL'yi kabul edebilir ve istemci tarafı kodunun neyin görüntüleneceğine karar vermesine izin verebilirsiniz.
Gezinme için HTML5 pushState kullanan uygulamaları desteklemek için yeniden yazmaları da kullanabilirsiniz. Bir tarayıcı, belirtilen source
veya regex
URL modeliyle eşleşen bir URL yolunu açmaya çalıştığında, tarayıcıya bunun yerine destination
URL'deki dosyanın içeriği verilecektir.
Bir nesne dizisi içeren bir rewrites
özelliği ("yeniden yazma kuralları" olarak adlandırılır) oluşturarak URL yeniden yazma işlemlerini belirtin. Her kuralda, istek URL yolu ile eşleştirildiğinde Hosting'in, hizmete belirtilen hedef URL verilmiş gibi yanıt vermesini tetikleyecek bir URL modeli belirtin.
Burada rewrites
özelliğinin temel yapısı verilmiştir. Bu örnek, mevcut olmayan dosya veya dizinlere yönelik istekler için index.html
sunar.
"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" } ] }
rewrites
özelliği, her kuralın aşağıdaki tabloda yer alan alanları içermesi gereken bir dizi yeniden yazma kuralı içerir.
Firebase Hosting, yalnızca belirtilen source
veya regex
URL modeliyle eşleşen bir URL yolunda bir dosya veya dizin mevcut değilse yeniden yazma kuralını uygular. Bir istek bir yeniden yazma kuralını tetiklediğinde tarayıcı, HTTP yeniden yönlendirmesi yerine belirtilen destination
dosyanın gerçek içeriğini döndürür.
Alan | Tanım | |
---|---|---|
rewrites | ||
source (önerilen)veya regex | İlk istek URL'si ile eşleştiğinde Hosting'i yeniden yazma işlemini tetikleyen bir URL modeli
| |
destination | Var olması gereken yerel bir dosya Bu URL göreceli veya mutlak bir yol olabilir. |
Bir işleve doğrudan istekler
Firebase Hosting URL'sinden bir işlev sunmak için rewrites
kullanabilirsiniz. Aşağıdaki örnek , Cloud Functions kullanılarak dinamik içerik sunma işleminden bir alıntıdır.
Örneğin, Hosting sitenizdeki /bigben
sayfasından gelen tüm istekleri bigben
işlevini yürütmek üzere yönlendirmek için:
"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)
}
} ]
}
hosting.rewrites
yapılandırmasının birfunction
bloğundanregion
çıkarılırsa Firebase CLI, bölgeyi işlevin kaynak kodundan otomatik olarak algılamaya çalışır; belirtilmediği takdirde varsayılan olarakus-central1
olur. İşlevin kaynak kodu kullanılamıyorsa CLI, dağıtılan işlevden bölgeyi algılamaya çalışır. İşlev birden fazla bölgedeyse CLI,region
hosting.rewrites
yapılandırmasında belirtilmesini gerektirir.
pinTag
özelliği yalnızca Cloud Functions for Firebase'de (2. nesil) mevcuttur. Bu özellik sayesinde, sitenizin dinamik içeriğini oluşturmaya yönelik her işlevin, statik Hosting kaynaklarınızla ve Hosting yapılandırmanızla senkronize tutulmasını sağlayabilirsiniz. Ayrıca bu özellik, Hosting önizleme kanallarındaki işlevlere yönelik yeniden yazma işlemlerinizi önizlemenize olanak tanır.
hosting.rewrites
yapılandırmasının birfunction
bloğuna"pinTag": true
eklerseniz, "sabitlenmiş" işleviçalıştırırken bile statik Hosting kaynaklarınız ve yapılandırmanızla birlikte dağıtılacaktır. Sitenizin bir sürümünü geri alırsanız "sabitlenmiş" işlevi de geri alınır.
firebase deploy --only hosting Bu özellik, hizmet başına 1000 etiket ve bölge başına 2000 etiket sınırına sahip Cloud Run etiketlerini temel alır. Bu, yüzlerce dağıtımdan sonra bir sitenin en eski sürümlerinin çalışmayı durdurabileceği anlamına gelir.
Bu yeniden yazma kuralını ekledikten ve Firebase'e dağıttıktan sonra ( firebase deploy
kullanarak), işlevinize aşağıdaki URL'ler aracılığıyla ulaşılabilir:
Firebase alt alan adlarınız:
PROJECT_ID .web.app/bigben
vePROJECT_ID .firebaseapp.com/bigben
Bağlı tüm özel alanlar :
CUSTOM_DOMAIN /bigben
İstekleri Hosting ile işlevlere yönlendirirken, desteklenen HTTP istek yöntemleri GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
ve OPTIONS
. REPORT
veya PROFIND
gibi diğer yöntemler desteklenmez.
Cloud Run kapsayıcısına doğrudan istekler
Firebase Barındırma URL'sinden bir Cloud Run kapsayıcısına erişmek için rewrites
kullanabilirsiniz. Aşağıdaki örnek, Cloud Run kullanılarak dinamik içerik sunma işleminden bir alıntıdır.
Örneğin, bir helloworld
kapsayıcı örneğinin başlatılmasını ve çalıştırılmasını tetiklemek amacıyla Hosting sitenizdeki /helloworld
sayfasından gelen tüm istekleri yönlendirmek için:
"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)
}
} ]
}
Bu özellik sayesinde, sitenizin dinamik içeriğini oluşturmak için Cloud Run hizmetinizin revizyonunun statik Hosting kaynaklarınızla ve Hosting yapılandırmanızla senkronize olmasını sağlayabilirsiniz. Ayrıca bu özellik, Hosting önizleme kanallarında Cloud Run'a yeniden yazma işlemlerinizi önizlemenize olanak tanır.
hosting.rewrites
yapılandırmasının birrun
bloğuna"pingTag": true
eklerseniz statik Barındırma kaynaklarınız ve yapılandırmanız, dağıtım sırasında Cloud Run hizmetinin en son revizyonuna sabitlenir. Sitenizin bir sürümünü geri alırsanız "sabitlenmiş" Cloud Run hizmetinin revizyonu da geri alınır.Bu özellik, hizmet başına 1000 etiket ve bölge başına 2000 etiket sınırına sahip Cloud Run etiketlerini temel alır. Bu, yüzlerce dağıtımdan sonra bir sitenin en eski sürümlerinin çalışmayı durdurabileceği anlamına gelir.
Bu yeniden yazma kuralını ekledikten ve Firebase'e dağıttıktan sonra ( firebase deploy
kullanılarak), kapsayıcı görüntünüze aşağıdaki URL'ler aracılığıyla ulaşılabilir:
Firebase alt alan adlarınız:
PROJECT_ID .web.app/helloworld
vePROJECT_ID .firebaseapp.com/helloworld
Bağlı tüm özel alanlar :
CUSTOM_DOMAIN /helloworld
İstekler Hosting ile Cloud Run kapsayıcılarına yönlendirilirken desteklenen HTTP istek yöntemleri GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
ve OPTIONS
. REPORT
veya PROFIND
gibi diğer yöntemler desteklenmez.
En iyi performansı elde etmek için aşağıdaki bölgeleri kullanarak Cloud Run hizmetinizi Barındırma ile birlikte konumlandırın:
-
us-west1
-
us-central1
-
us-east1
-
europe-west1
-
asia-east1
Hosting'den Cloud Run'a yeniden yazma işlemleri aşağıdaki bölgelerde desteklenir:
-
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
Özel etki alanı Dinamik Bağlantıları oluşturun
Özel etki alanı Dinamik Bağlantıları oluşturmak için rewrites
kullanabilirsiniz. Dinamik Bağlantılar için özel bir alan adı ayarlama hakkında ayrıntılı bilgi için Dinamik Bağlantılar belgelerini ziyaret edin.
Özel alan adınızı yalnızca Dinamik Bağlantılar için kullanın
"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 } ] }
Dinamik Bağlantılar için kullanılacak özel etki alanı yolu öneklerini belirtme
"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 } ] }
firebase.json
dosyanızda Dinamik Bağlantıları yapılandırmak aşağıdakileri gerektirir:
Alan | Tanım | |
---|---|---|
appAssociation |
| |
rewrites | ||
source | Dinamik Bağlantılar için kullanmak istediğiniz yol URL'lere giden yolları yeniden yazan kuralların aksine, Dinamik Bağlantılar için yeniden yazma kuralları normal ifadeler içeremez. | |
dynamicLinks | true olarak ayarlanmalıdır |
Başlıkları yapılandırma
İsteğe bağlı
Başlıklar, istemcinin ve sunucunun bir istek veya yanıtla birlikte ek bilgiler iletmesine olanak tanır. Bazı başlık kümeleri, erişim kontrolü, kimlik doğrulama, önbelleğe alma ve kodlama dahil olmak üzere tarayıcının sayfayı ve içeriğini nasıl işlediğini etkileyebilir.
Bir dizi başlık nesnesi içeren bir headers
niteliği oluşturarak özel, dosyaya özgü yanıt başlıklarını belirtin. Her nesnede, istek URL yolu ile eşleştirildiğinde Hosting'in belirtilen özel yanıt başlıklarını uygulamasını tetikleyecek bir URL modeli belirtin.
Burada headers
özelliğinin temel yapısı verilmiştir. Bu örnek, tüm yazı tipi dosyalarına bir CORS başlığı uygular.
"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" } ] } ] }
headers
özelliği, her tanımın aşağıdaki tabloda yer alan alanları içermesi gereken bir dizi tanım içerir.
Alan | Tanım | ||
---|---|---|---|
headers | |||
source (önerilen)veya regex | İlk istek URL'siyle eşleştirildiğinde Hosting'in özel başlığı uygulamasını tetikleyen bir URL modeli
Özel 404 sayfanızla eşleşecek bir başlık oluşturmak için | ||
(alt) headers dizisi | Hosting'in istek yoluna uyguladığı özel başlıklar Her alt başlık bir | ||
key | Başlığın adı, örneğin Cache-Control | ||
value | Başlığın değeri; örneğin max-age=7200 |
Dinamik içerik sunmayı ve mikro hizmetleri barındırmayı açıklayan Barındırma bölümünde Cache-Control
hakkında daha fazla bilgi edinebilirsiniz. Ayrıca CORS üstbilgileri hakkında daha fazla bilgi edinebilirsiniz.
.html
uzantılarını kontrol edin
İsteğe bağlı
cleanUrls
özelliği, URL'lerin .html
uzantısını içerip içermeyeceğini kontrol etmenize olanak tanır.
true
olduğunda, Hosting .html
uzantısını yüklenen dosya URL'lerinden otomatik olarak çıkarır. İsteğe bir .html
uzantısı eklenirse Hosting aynı yola 301
yönlendirmesi gerçekleştirir ancak .html
uzantısını ortadan kaldırır.
Bir cleanUrls
özelliği ekleyerek URL'lere .html
eklenmesinin nasıl kontrol edileceği aşağıda açıklanmıştır:
"hosting": {
// ...
// Drops `.html` from uploaded URLs
"cleanUrls": true
}
Sondaki eğik çizgileri kontrol et
İsteğe bağlı
trailingSlash
özelliği, statik içerik URL'lerinin sonunda eğik çizgi içerip içermeyeceğini kontrol etmenize olanak tanır.
-
true
olduğunda, Hosting URL'leri sonuna eğik çizgi ekleyecek şekilde yönlendirir. -
false
olduğunda, Hosting URL'leri sondaki eğik çizgiyi kaldıracak şekilde yönlendirir. - Belirtilmediğinde Hosting, dizin dizini dosyaları için yalnızca sondaki eğik çizgileri kullanır (örneğin,
about/index.html
).
trailingSlash
niteliğini ekleyerek sondaki eğik çizgileri nasıl kontrol edeceğiniz aşağıda açıklanmıştır:
"hosting": {
// ...
// Removes trailing slashes from URLs
"trailingSlash": false
}
trailingSlash
özelliği, Cloud Functions veya Cloud Run tarafından sunulan dinamik içeriğe yönelik yeniden yazma işlemlerini etkilemez.
Glob desen eşleştirme
Firebase Hosting yapılandırma seçenekleri, Git'in gitignore
kurallarını ve Bower'ın ignore
kurallarını işleme biçimine benzer şekilde, extglob ile glob modeli eşleştirme notasyonunu kapsamlı bir şekilde kullanır. Bu wiki sayfası daha ayrıntılı bir referanstır ancak aşağıda bu sayfada kullanılan örneklerin açıklamaları yer almaktadır:
firebase.json
— Yalnızcapublic
dizinin kökündekifirebase.json
dosyasıyla eşleşir**
— Herhangi bir alt dizindeki herhangi bir dosya veya klasörle eşleşir*
— Yalnızcapublic
dizinin kökündeki dosya ve klasörlerle eşleşir**/.*
— ile başlayan herhangi bir dosyayla eşleşir.
(genellikle.git
klasöründeki gibi gizli dosyalar) rastgele bir alt dizinde**/node_modules/**
— Birnode_modules
klasörünün rastgele bir alt dizinindeki herhangi bir dosya veya klasörle eşleşir; bu dosyanın kendisi depublic
dizinin isteğe bağlı bir alt dizininde olabilir**/*.@(jpg|jpeg|gif|png)
— Rastgele bir alt dizindeki aşağıdakilerden tam olarak biriyle biten herhangi bir dosyayla eşleşir:.jpg
,.jpeg
,.gif
veya.png
Tam Barındırma yapılandırma örneği
Aşağıda Firebase Hosting için tam bir firebase.json
yapılandırma örneği verilmiştir. firebase.json
dosyasının diğer Firebase hizmetlerine ilişkin yapılandırmaları da içerebileceğini unutmayın.
{
"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",
}
}