ด้วย Firebase Hosting คุณสามารถกำหนดค่าพฤติกรรมการโฮสต์แบบกำหนดเองสำหรับคำขอไปยังเว็บไซต์ของคุณ
คุณสามารถกำหนดค่าอะไรสำหรับโฮสติ้ง?
ระบุไฟล์ในไดเร็กทอรีโปรเจ็กต์ในเครื่องที่คุณต้องการปรับใช้กับ Firebase Hosting เรียนรู้วิธีการ
แสดงหน้า 404/ไม่พบที่กำหนดเอง เรียนรู้วิธีการ
ตั้งค่า
redirects
สำหรับเพจที่คุณย้ายหรือลบ เรียนรู้วิธีการตั้งค่าการ
rewrites
เพื่อวัตถุประสงค์ใด ๆ เหล่านี้:แสดงเนื้อหาเดียวกันสำหรับ URL หลายรายการ เรียนรู้วิธีการ
ให้บริการฟังก์ชันหรือเข้าถึงคอนเทนเนอร์ Cloud Run จาก Hosting URL เรียนรู้วิธีการ: ฟังก์ชั่น หรือ คอนเทนเนอร์
สร้างไดนามิกลิงก์โดเมนที่กำหนดเอง เรียนรู้วิธีการ
เพิ่ม
headers
เพื่อส่งต่อข้อมูลเพิ่มเติมเกี่ยวกับคำขอหรือการตอบกลับ เช่น วิธีที่เบราว์เซอร์ควรจัดการหน้าและเนื้อหาของหน้า (การตรวจสอบสิทธิ์ การแคช การเข้ารหัส ฯลฯ) เรียนรู้วิธีการตั้งค่าการทำให้เป็นสากล (i18n) การเขียนใหม่เพื่อแสดงเนื้อหาเฉพาะตามการตั้งค่าภาษาของผู้ใช้และ/หรือประเทศ เรียนรู้วิธีการ (หน้าต่าง)
คุณกำหนดการกำหนดค่าโฮสติ้งของคุณไว้ที่ใด
คุณกำหนดการกำหนดค่าโฮสติ้งของ Firebase ในไฟล์ firebase.json
Firebase จะสร้างไฟล์ firebase.json
ที่รูทของไดเร็กทอรีโปรเจ็กต์ของคุณโดยอัตโนมัติเมื่อคุณรันคำสั่ง firebase init
คุณสามารถดู ตัวอย่างการกำหนดค่า firebase.json
แบบเต็ม (ครอบคลุมเฉพาะโฮสติ้งของ Firebase) ที่ด้านล่างของหน้านี้ โปรดทราบว่าไฟล์ firebase.json
ยังสามารถมี การกำหนดค่าสำหรับบริการ Firebase อื่นๆ
คุณสามารถตรวจสอบเนื้อหา firebase.json
ปรับใช้ได้โดยใช้ Hosting REST API
ลำดับความสำคัญของการตอบกลับของ Hosting
ตัวเลือกการกำหนดค่า Firebase Hosting ต่างๆ ที่อธิบายไว้ในหน้านี้บางครั้งอาจทับซ้อนกัน หากมีข้อขัดแย้ง Hosting จะกำหนดการตอบสนองโดยใช้ลำดับความสำคัญต่อไปนี้:
- เนมสเปซที่สงวนไว้ซึ่งขึ้นต้นด้วย
/__/*
ส่วนเส้นทาง - การกำหนดค่า การเปลี่ยนเส้นทาง
- เนื้อหาคงที่ตรงทั้งหมด
- กำหนดค่า เขียนใหม่
- กำหนดเอง 404 หน้า
- หน้า 404 เริ่มต้น
หากคุณใช้ i18n rewrites ลำดับความสำคัญในการจัดการการจับคู่แบบตรงทั้งหมดและ 404 จะถูกขยายขอบเขตเพื่อรองรับ "เนื้อหา i18n" ของคุณ
ระบุไฟล์ที่จะปรับใช้
แอตทริบิวต์เริ่มต้น — public
และ ignore
— รวมอยู่ในไฟล์ firebase.json
เริ่มต้นกำหนดว่าไฟล์ใดในไดเรกทอรีโปรเจ็กต์ของคุณควรปรับใช้กับโปรเจ็กต์ Firebase
การกำหนดค่า hosting
เริ่มต้นในไฟล์ firebase.json
มีลักษณะดังนี้:
"hosting": {
"public": "public", // the only required attribute for Hosting
"ignore": [
"firebase.json",
"**/.*",
"**/node_modules/**"
]
}
สาธารณะ
ที่จำเป็น
แอตทริบิวต์ public
ระบุไดเรกทอรีที่จะปรับใช้กับโฮสติ้งของ Firebase ค่าเริ่มต้นคือไดเร็กทอรีชื่อ public
แต่คุณสามารถระบุพาธของไดเร็กทอรีใดก็ได้ ตราบใดที่ยังมีอยู่ในไดเร็กทอรีโครงการของคุณ
ต่อไปนี้เป็นชื่อเริ่มต้นที่ระบุของไดเร็กทอรีที่จะปรับใช้:
"hosting": {
"public": "public"
// ...
}
คุณสามารถเปลี่ยนค่าเริ่มต้นเป็นไดเร็กทอรีที่คุณต้องการปรับใช้:
"hosting": {
"public": "dist/app"
// ...
}
ไม่สนใจ
ไม่จำเป็น
แอตทริบิวต์ ignore
ระบุไฟล์ที่จะละเว้นในการปรับใช้ มันสามารถใช้ globs ได้เช่นเดียวกับที่ Git จัดการ .gitignore
ต่อไปนี้เป็นค่าเริ่มต้นสำหรับไฟล์ที่จะละเว้น:
"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/ไม่พบ
ไม่จำเป็น
คุณสามารถแสดงข้อผิดพลาด 404 Not Found
แบบกำหนดเองได้เมื่อผู้ใช้พยายามเข้าถึงหน้าที่ไม่มีอยู่
สร้างไฟล์ใหม่ใน ไดเร็กทอรี public
ของโปรเจ็กต์ของคุณ ตั้งชื่อว่า 404.html
จากนั้นเพิ่มเนื้อหา 404 Not Found
ที่คุณกำหนดเองลงในไฟล์
Firebase Hosting จะแสดงเนื้อหาของหน้า 404.html
ที่กำหนดเองนี้ หากเบราว์เซอร์เรียกข้อผิดพลาด 404 Not Found
บนโดเมนหรือโดเมนย่อยของคุณ
กำหนดค่าการเปลี่ยนเส้นทาง
ไม่จำเป็น
ใช้การเปลี่ยนเส้นทาง URL เพื่อป้องกันลิงก์เสีย หากคุณได้ย้ายหน้าหรือย่อ URL ตัวอย่างเช่น คุณสามารถเปลี่ยนเส้นทางเบราว์เซอร์จาก example.com/team
ไปยัง example.com/about.html
ระบุการเปลี่ยนเส้นทาง URL โดยการสร้างแอตทริบิวต์การ redirects
ที่มีอาร์เรย์ของวัตถุ (เรียกว่า "กฎการเปลี่ยนเส้นทาง") ในแต่ละกฎ ระบุรูปแบบ URL ที่หากตรงกับเส้นทาง URL คำขอ จะเรียก Hosting ให้ตอบสนองด้วยการเปลี่ยนเส้นทางไปยัง URL ปลายทางที่ระบุ
นี่คือโครงสร้างพื้นฐานสำหรับแอตทริบิวต์การ redirects
ตัวอย่างนี้เปลี่ยนเส้นทางคำขอไปยัง /foo
โดยส่งคำขอใหม่ไปที่ /bar
"hosting": {
// ...
// Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
"redirects": [ {
"source": "/foo",
"destination": "/bar",
"type": 301
} ]
}
"hosting": {
// ...
// Add the "redirects" attribute within "hosting"
"redirects": [ {
// Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
"source": "/foo",
"destination": "/bar",
"type": 301
}, {
// Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
"source": "/foo{,/**}"
"destination": "/bar"
"type": 301
}, {
// Returns a temporary redirect for all requests to files or directories in the "firebase" directory
"source": "/firebase/**",
"destination": "https://firebase.google.com/",
"type": 302
}, {
// A regular expression-based redirect equivalent to the above behavior
"regex": "/firebase/.*",
"destination": "https://firebase.google.com/",
"type": 302
} ]
}
แอตทริบิวต์ redirects
มีอาร์เรย์ของกฎการเปลี่ยนเส้นทาง ซึ่งแต่ละกฎต้องมีฟิลด์ในตารางด้านล่าง
Firebase Hosting เปรียบเทียบ source
หรือค่า regex
กับเส้นทาง URL ทั้งหมดที่จุดเริ่มต้นของทุกคำขอ (ก่อนที่เบราว์เซอร์จะกำหนดว่าไฟล์หรือโฟลเดอร์อยู่ที่เส้นทางนั้นหรือไม่) หากพบรายการที่ตรงกัน เซิร์ฟเวอร์ต้นทางของ Firebase Hosting จะส่งการตอบสนองการเปลี่ยนเส้นทาง HTTPS เพื่อแจ้งให้เบราว์เซอร์สร้างคำขอใหม่ที่ URL destination
สนาม | คำอธิบาย | |
---|---|---|
redirects | ||
source (แนะนำ)หรือ regex | รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น จะทริกเกอร์การโฮสต์เพื่อใช้การเปลี่ยนเส้นทาง
| |
destination | URL แบบคงที่ที่เบราว์เซอร์ควรทำคำขอใหม่ URL นี้สามารถเป็นเส้นทางแบบสัมพัทธ์หรือแบบสัมบูรณ์ | |
type | รหัสตอบกลับ HTTPS
|
จับกลุ่ม URL สำหรับการเปลี่ยนเส้นทาง
ไม่จำเป็น
บางครั้ง คุณอาจต้องบันทึกกลุ่มเฉพาะของรูปแบบ URL ของกฎการเปลี่ยนเส้นทาง (ค่า source
หรือค่า regex
) จากนั้นใช้กลุ่มเหล่านี้ซ้ำในเส้นทาง destination
ของกฎ
หากคุณกำลังใช้ฟิลด์ source
(นั่นคือ การระบุ glob สำหรับรูปแบบ URL ของคุณ) คุณสามารถบันทึกกลุ่มโดยใส่ :
นำหน้าเพื่อระบุกลุ่ม หากคุณต้องการบันทึกเส้นทาง URL ที่เหลือหลังจากกลุ่ม ให้ใส่ *
ต่อจากกลุ่มทันที ตัวอย่างเช่น:
"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 } ] }
หากคุณกำลังใช้ฟิลด์ regex
(นั่นคือ การระบุนิพจน์ทั่วไป RE2 สำหรับรูปแบบ URL ของคุณ) คุณสามารถจับภาพเซ็กเมนต์ได้โดยใช้แคปเจอร์กรุ๊ป RE2 ที่มีชื่อหรือไม่มีชื่อ กลุ่มแคปเจอร์ที่มีชื่อสามารถใช้ได้ในฟิลด์ destination
ด้วยคำนำหน้า :
ในขณะที่แคปเจอร์กรุ๊ปที่ไม่มีชื่อสามารถอ้างอิงได้ด้วยดัชนีตัวเลขในค่า regex
โดยสร้างดัชนีจาก 1 ตัวอย่างเช่น
"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 } ] }
กำหนดค่าการเขียนใหม่
ไม่จำเป็น
ใช้การเขียนใหม่เพื่อแสดงเนื้อหาเดียวกันสำหรับ URL หลายรายการ การเขียนซ้ำมีประโยชน์อย่างยิ่งกับการจับคู่รูปแบบ เนื่องจากคุณสามารถยอมรับ URL ใดๆ ที่ตรงกับรูปแบบ และให้โค้ดฝั่งไคลเอ็นต์ตัดสินใจว่าจะแสดงอะไร
คุณยังสามารถใช้การเขียนซ้ำเพื่อรองรับแอปที่ใช้ HTML5 pushState สำหรับการนำทาง เมื่อเบราว์เซอร์พยายามเปิดเส้นทาง URL ที่ตรงกับ source
ที่มาหรือรูปแบบ URL regex
ที่ระบุ เบราว์เซอร์จะได้รับเนื้อหาของไฟล์ที่ URL destination
แทน
ระบุการเขียน URL ใหม่โดยการสร้างแอตทริบิวต์การ rewrites
ที่มีอาร์เรย์ของวัตถุ (เรียกว่า "กฎการเขียนซ้ำ") ในแต่ละกฎ ให้ระบุรูปแบบ URL ที่หากตรงกับเส้นทาง URL คำขอ จะเรียก Hosting ให้ตอบสนองราวกับว่าบริการได้รับ URL ปลายทางที่ระบุ
นี่คือโครงสร้างพื้นฐานสำหรับแอตทริบิวต์การ rewrites
ตัวอย่างนี้ให้บริการ index.html
สำหรับการร้องขอไปยังไฟล์หรือไดเร็กทอรีที่ไม่มีอยู่
"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
มีอาร์เรย์ของกฎการเขียนซ้ำ โดยที่แต่ละกฎต้องมีฟิลด์ในตารางด้านล่าง
Firebase Hosting จะใช้กฎการเขียนใหม่ก็ต่อเมื่อไม่มีไฟล์หรือไดเรกทอรีอยู่ที่เส้นทาง URL ที่ตรงกับ source
ที่มาที่ระบุหรือรูปแบบ URL ของ regex
เมื่อคำขอทริกเกอร์กฎการเขียนซ้ำ เบราว์เซอร์จะส่งคืนเนื้อหาจริงของไฟล์ destination
ที่ระบุแทนการเปลี่ยนเส้นทาง HTTP
สนาม | คำอธิบาย | |
---|---|---|
rewrites | ||
source (แนะนำ)หรือ regex | รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น โฮสต์จะใช้การเขียนใหม่
| |
destination | ไฟล์ในเครื่องที่ต้องมีอยู่ URL นี้สามารถเป็นเส้นทางแบบสัมพัทธ์หรือแบบสัมบูรณ์ |
คำขอโดยตรงไปยังฟังก์ชัน
คุณสามารถใช้การ rewrites
เพื่อแสดงฟังก์ชันจาก Firebase Hosting URL ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การให้บริการเนื้อหาแบบไดนามิกโดยใช้ Cloud Functions
ตัวอย่างเช่น หากต้องการส่งคำขอทั้งหมดจากหน้า /bigben
บนไซต์โฮสติ้งของคุณเพื่อดำเนินการฟังก์ชัน bigben
:
"hosting": {
// ...
// Directs all requests from the page `/bigben` to execute the `bigben` function
"rewrites": [ {
"source": "/bigben",
"function": "bigben"
} ]
}
หลังจากเพิ่มกฎการเขียนซ้ำนี้และปรับใช้กับ Firebase (โดยใช้ firebase deploy
) ฟังก์ชันของคุณจะสามารถเข้าถึงได้ผ่าน URL ต่อไปนี้:
โดเมนย่อย Firebase ของคุณ:
PROJECT_ID .web.app/bigben
และPROJECT_ID .firebaseapp.com/bigben
โดเมนที่กำหนดเองที่ เชื่อมต่อใดๆ :
CUSTOM_DOMAIN /bigben
เมื่อเปลี่ยนเส้นทางคำขอไปยังฟังก์ชันด้วย Hosting วิธีการขอ HTTP ที่รองรับคือ GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
และ OPTIONS
ไม่รองรับวิธีการอื่นๆ เช่น REPORT
หรือ PROFIND
ส่งคำขอโดยตรงไปยังคอนเทนเนอร์ Cloud Run
คุณสามารถใช้การ rewrites
เพื่อเข้าถึงคอนเทนเนอร์ Cloud Run จาก Firebase Hosting URL ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การแสดงเนื้อหาแบบไดนามิกโดยใช้ Cloud Run
ตัวอย่างเช่น หากต้องการส่งคำขอทั้งหมดจากหน้า /helloworld
บนไซต์โฮสติ้งของคุณเพื่อทริกเกอร์การเริ่มต้นและเรียกใช้อินสแตนซ์คอนเทนเนอร์ของ 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)
}
} ]
}
หลังจากเพิ่มกฎการเขียนซ้ำนี้และปรับใช้กับ Firebase (โดยใช้ firebase deploy
) อิมเมจคอนเทนเนอร์ของคุณจะสามารถเข้าถึงได้ผ่าน URL ต่อไปนี้:
โดเมนย่อย Firebase ของคุณ:
PROJECT_ID .web.app/helloworld
และPROJECT_ID .firebaseapp.com/helloworld
โดเมนที่กำหนดเองที่ เชื่อมต่อใดๆ :
CUSTOM_DOMAIN /helloworld
เมื่อเปลี่ยนเส้นทางคำขอไปยังคอนเทนเนอร์ Cloud Run ด้วย Hosting วิธีการขอ HTTP ที่รองรับคือ GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
และ OPTIONS
ไม่รองรับวิธีการอื่นๆ เช่น REPORT
หรือ PROFIND
ปัจจุบัน คุณสามารถใช้ Cloud Run เขียนซ้ำกับโฮสติ้งได้ในภูมิภาคต่อไปนี้:
-
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
สร้างโดเมนที่กำหนดเอง Dynamic Links
คุณสามารถใช้การ rewrites
เพื่อสร้างลิงก์แบบไดนามิกของโดเมนที่กำหนดเอง ไปที่เอกสารประกอบ Dynamic Links สำหรับข้อมูลโดยละเอียดเกี่ยวกับ การตั้งค่าโดเมนที่กำหนดเองสำหรับ 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 } ] }
ระบุคำนำหน้าเส้นทางโดเมนที่กำหนดเองเพื่อใช้สำหรับ 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 } ] }
การกำหนดค่าลิงก์แบบไดนามิกในไฟล์ firebase.json
ของคุณต้องการสิ่งต่อไปนี้:
สนาม | คำอธิบาย | |
---|---|---|
appAssociation | ต้องตั้งค่าเป็น
| |
rewrites | ||
source | เส้นทางที่คุณต้องการใช้สำหรับ Dynamic Links ไม่เหมือนกับกฎที่เขียนเส้นทางไปยัง URL ใหม่ โดยการเขียนกฎใหม่สำหรับลิงก์แบบไดนามิกต้องไม่มีนิพจน์ทั่วไป | |
dynamicLinks | ต้องตั้งค่า true |
กำหนดค่าส่วนหัว
ไม่จำเป็น
ส่วนหัวช่วยให้ไคลเอนต์และเซิร์ฟเวอร์ส่งข้อมูลเพิ่มเติมพร้อมกับคำขอหรือคำตอบ ส่วนหัวบางชุดอาจส่งผลต่อวิธีที่เบราว์เซอร์จัดการเพจและเนื้อหา รวมถึงการควบคุมการเข้าถึง การตรวจสอบสิทธิ์ การแคช และการเข้ารหัส
ระบุส่วนหัวการตอบกลับเฉพาะไฟล์แบบกำหนดเองโดยการสร้างแอตทริบิวต์ headers
ที่มีอาร์เรย์ของวัตถุส่วนหัว ในแต่ละอ็อบเจ็กต์ ระบุรูปแบบ URL ที่หากตรงกับเส้นทาง URL คำขอ โฮสติ้งจะใช้ส่วนหัวการตอบสนองที่กำหนดเองที่ระบุ
นี่คือโครงสร้างพื้นฐานสำหรับแอตทริบิวต์ headers
ตัวอย่างนี้ใช้ส่วนหัว CORS สำหรับไฟล์ฟอนต์ทั้งหมด
"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
ประกอบด้วยอาร์เรย์ของคำจำกัดความ ซึ่งแต่ละคำนิยามต้องมีฟิลด์ในตารางด้านล่าง
สนาม | คำอธิบาย | ||
---|---|---|---|
headers | |||
source (แนะนำ)หรือ regex | รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น โฮสต์จะใช้ส่วนหัวที่กำหนดเอง
หากต้องการสร้างส่วนหัวให้ตรงกับ หน้า 404 ที่กำหนดเอง ให้ใช้ | ||
อาร์เรย์ของ headers (ย่อย) | ส่วนหัวที่กำหนดเองที่ Hosting ใช้กับเส้นทางคำขอ ส่วนหัวย่อยแต่ละรายการต้องมี คู่ | ||
key | ชื่อของส่วนหัว เช่น Cache-Control | ||
value | ค่าสำหรับส่วนหัว เช่น max-age=7200 |
คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ Cache-Control
ได้ในส่วนการโฮสต์ที่อธิบายการให้บริการเนื้อหาแบบไดนามิกและการโฮสต์ไมโครเซอร์วิส คุณยังสามารถเรียนรู้เพิ่มเติมเกี่ยวกับส่วนหัว CORS
ควบคุมส่วนขยาย .html
ไม่จำเป็น
แอตทริบิวต์ cleanUrls
ช่วยให้คุณควบคุมได้ว่าจะให้ URL รวมส่วนขยาย .html
หรือไม่
เมื่อ true
โฮสติ้งจะลบนามสกุล .html
จาก URL ของไฟล์ที่อัปโหลดโดยอัตโนมัติ หากมีการเพิ่มส่วนขยาย .html
ในคำขอ โฮสติ้งจะทำการเปลี่ยนเส้นทาง 301
ไปยังเส้นทางเดียวกัน แต่จะลบส่วนขยาย .html
ต่อไปนี้คือวิธีการควบคุมการรวม .html
ใน URL โดยการรวมแอตทริบิวต์ cleanUrls
:
"hosting": {
// ...
// Drops `.html` from uploaded URLs
"cleanUrls": true
}
ควบคุมเครื่องหมายทับ
ไม่จำเป็น
แอตทริบิวต์ trailingSlash
ช่วยให้คุณควบคุมได้ว่า URL เนื้อหาแบบคงที่ควรมีเครื่องหมายทับต่อท้ายหรือไม่
- เมื่อ
true
โฮสติ้งจะเปลี่ยนเส้นทาง URL เพื่อเพิ่มเครื่องหมายทับ - เมื่อ
false
โฮสติ้งจะเปลี่ยนเส้นทาง URL เพื่อลบเครื่องหมายทับ - เมื่อไม่ได้ระบุ Hosting จะใช้สแลชต่อท้ายสำหรับไฟล์ดัชนีไดเรกทอรีเท่านั้น (เช่น
about/index.html
)
ต่อไปนี้คือวิธีควบคุมเครื่องหมายทับโดยการเพิ่มแอตทริบิวต์ trailingSlash
:
"hosting": {
// ...
// Removes trailing slashes from URLs
"trailingSlash": false
}
แอตทริบิวต์ trailingSlash
ไม่มีผลกับการเขียนซ้ำไปยังเนื้อหาแบบไดนามิกที่ให้บริการโดย Cloud Functions หรือ Cloud Run
การจับคู่รูปแบบ Glob
ตัวเลือกการกำหนดค่าโฮสติ้งของ Firebase ใช้ รูปแบบการจับคู่รูปแบบ glob กับ extglob อย่างกว้างขวาง คล้ายกับที่ Git จัดการกับกฎ gitignore
และ Bower จัดการกับการ ignore
กฎ หน้า Wiki นี้ เป็นข้อมูลอ้างอิงโดยละเอียด แต่ต่อไปนี้คือคำอธิบายของตัวอย่างที่ใช้ในหน้านี้:
firebase.json
— จับคู่เฉพาะไฟล์firebase.json
ในรูทของไดเรกทอรีpublic
**
— จับคู่ไฟล์หรือโฟลเดอร์ใด ๆ ในไดเร็กทอรีย่อยโดยพลการ*
— จับคู่เฉพาะไฟล์และโฟลเดอร์ในรูทของไดเรกทอรีpublic
**/.*
— จับคู่ไฟล์ที่ขึ้นต้นด้วย.
(โดยปกติคือไฟล์ที่ซ่อนอยู่ เช่น ในโฟลเดอร์.git
) ในไดเร็กทอรีย่อยตามอำเภอใจ**/node_modules/**
— จับคู่ไฟล์หรือโฟลเดอร์ใดๆ ในไดเร็กทอรีย่อยของโฟลเดอร์node_modules
ซึ่งสามารถอยู่ในไดเร็กทอรีย่อยของไดเร็กทอรีpublic
**/*.@(jpg|jpeg|gif|png)
— จับคู่ไฟล์ใดๆ ในไดเร็กทอรีย่อยที่ลงท้ายด้วยสิ่งใดสิ่งหนึ่งต่อไปนี้:.jpg
,.jpeg
,.gif
หรือ ..png
ตัวอย่างการกำหนดค่าโฮสติ้งแบบเต็ม
ต่อไปนี้คือตัวอย่างการกำหนดค่า firebase.json
แบบเต็มสำหรับ Firebase Hosting โปรดทราบว่าไฟล์ firebase.json
สามารถมี การกำหนดค่าสำหรับบริการ 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",
}
}