ด้วย Firebase Hosting คุณสามารถกำหนดค่าพฤติกรรมการโฮสต์ที่กำหนดเองสำหรับคำขอไปยังไซต์ของคุณได้
คุณสามารถกำหนดค่าอะไรให้กับโฮสติ้งได้บ้าง?
ระบุไฟล์ในไดเรกทอรีโปรเจ็กต์ในเครื่องที่คุณต้องการปรับใช้กับโฮสติ้ง Firebase เรียนรู้วิธีการ
แสดงหน้า 404/Not Found ที่กำหนดเอง เรียนรู้วิธีการ
ตั้งค่า
redirects
สำหรับเพจที่คุณย้ายหรือลบ เรียนรู้วิธีการตั้งค่า
rewrites
เพื่อวัตถุประสงค์เหล่านี้:แสดงเนื้อหาเดียวกันสำหรับหลาย URL เรียนรู้วิธีการ
ให้บริการฟังก์ชันหรือเข้าถึงคอนเทนเนอร์ Cloud Run จาก URL โฮสติ้ง เรียนรู้วิธีการ: ฟังก์ชั่น หรือ คอนเทนเนอร์
สร้างโดเมนไดนามิกลิงก์แบบกำหนดเอง เรียนรู้วิธีการ
เพิ่ม
headers
เพื่อส่งข้อมูลเพิ่มเติมเกี่ยวกับคำขอหรือการตอบกลับ เช่น วิธีที่เบราว์เซอร์ควรจัดการกับเพจและเนื้อหาในหน้านั้น (การตรวจสอบสิทธิ์ การแคช การเข้ารหัส ฯลฯ) เรียนรู้วิธีการตั้งค่าการเขียนใหม่ให้เป็นสากล (i18n) เพื่อแสดงเนื้อหาเฉพาะตามการตั้งค่าภาษาและ/หรือประเทศของผู้ใช้ เรียนรู้วิธีการ (หน้าอื่น)
คุณกำหนดการกำหนดค่าโฮสติ้งของคุณที่ไหน?
คุณกำหนดการกำหนดค่าโฮสติ้ง Firebase ในไฟล์ firebase.json
Firebase จะสร้างไฟล์ firebase.json
ของคุณที่รากของไดเรกทอรีโปรเจ็กต์ของคุณโดยอัตโนมัติเมื่อคุณเรียกใช้คำสั่ง firebase init
คุณสามารถดู ตัวอย่างการกำหนดค่า firebase.json
แบบเต็ม (ครอบคลุมเฉพาะโฮสติ้ง Firebase เท่านั้น) ได้ที่ด้านล่างของหน้านี้ โปรดทราบว่าไฟล์ firebase.json
อาจมี การกำหนดค่าสำหรับบริการ Firebase อื่นๆ ได้ด้วย
คุณสามารถตรวจสอบเนื้อหา firebase.json
ที่ปรับใช้ได้โดยใช้ Hosting REST API
ลำดับความสำคัญของการตอบกลับโฮสติ้ง
ตัวเลือกการกำหนดค่าโฮสติ้ง Firebase ต่างๆ ที่อธิบายไว้ในหน้านี้บางครั้งอาจทับซ้อนกันได้ หากมีข้อขัดแย้ง โฮสติ้งจะพิจารณาการตอบสนองโดยใช้ลำดับความสำคัญต่อไปนี้:
- เนมสเปซที่สงวนไว้ซึ่งขึ้นต้นด้วยส่วนเส้นทาง
/__/*
- การเปลี่ยนเส้นทาง ที่กำหนดค่าไว้
- เนื้อหาคงที่ที่ตรงทั้งหมด
- กำหนด ค่าการเขียนใหม่ แล้ว
- หน้า 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 Hosting ค่าเริ่มต้นคือไดเร็กทอรีชื่อ 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/Not Found
ไม่จำเป็น
คุณสามารถแสดงข้อผิดพลาด 404 Not Found
แบบกำหนดเองได้เมื่อผู้ใช้พยายามเข้าถึงเพจที่ไม่มีอยู่
สร้างไฟล์ใหม่ใน ไดเร็กทอรี public
ของโปรเจ็กต์ของคุณ ตั้งชื่อเป็น 404.html
จากนั้นเพิ่มเนื้อหา 404 Not Found
ที่คุณกำหนดเองลงในไฟล์
โฮสติ้ง Firebase จะแสดงเนื้อหาของหน้า 404.html
ที่กำหนดเองนี้ หากเบราว์เซอร์ทำให้เกิดข้อผิดพลาด 404 Not Found
ในโดเมนหรือโดเมนย่อยของคุณ
กำหนดค่าการเปลี่ยนเส้นทาง
ไม่จำเป็น
ใช้การเปลี่ยนเส้นทาง URL เพื่อป้องกันลิงก์เสียหากคุณย้ายหน้าหรือย่อ URL ตัวอย่างเช่น คุณสามารถเปลี่ยนเส้นทางเบราว์เซอร์จาก example.com/team
ไปยัง example.com/about.html
ระบุการเปลี่ยนเส้นทาง URL โดยการสร้างแอตทริบิวต์ redirects
ที่มีอาร์เรย์ของวัตถุ (เรียกว่า "กฎการเปลี่ยนเส้นทาง") ในแต่ละกฎ ให้ระบุรูปแบบ URL ที่หากตรงกับเส้นทาง URL คำขอ จะทริกเกอร์โฮสติ้งให้ตอบสนองด้วยการเปลี่ยนเส้นทางไปยัง 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 จะเปรียบเทียบ source
หรือค่า regex
กับเส้นทาง URL ทั้งหมดที่จุดเริ่มต้นของทุกคำขอ (ก่อนที่เบราว์เซอร์จะพิจารณาว่ามีไฟล์หรือโฟลเดอร์อยู่ที่เส้นทางนั้น) หากพบว่าตรงกัน เซิร์ฟเวอร์ต้นทางของโฮสติ้ง Firebase จะส่งการตอบสนองการเปลี่ยนเส้นทาง 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 คำขอ จะทริกเกอร์โฮสติ้งให้ตอบสนองเสมือนว่าบริการได้รับ 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 จะใช้กฎการเขียนซ้ำเฉพาะในกรณีที่ไฟล์หรือไดเรกทอรีไม่มีอยู่ในเส้นทาง URL ที่ตรงกับ source
ที่ระบุหรือรูปแบบ URL regex
เมื่อคำขอทริกเกอร์กฎการเขียนซ้ำ เบราว์เซอร์จะส่งกลับเนื้อหาจริงของไฟล์ destination
ที่ระบุแทนการเปลี่ยนเส้นทาง HTTP
สนาม | คำอธิบาย | |
---|---|---|
rewrites | ||
source (แนะนำ)หรือ regex | รูปแบบ URL ที่หากจับคู่กับ URL คำขอเริ่มต้น จะทริกเกอร์โฮสติ้งให้ใช้การเขียนใหม่
| |
destination | ไฟล์ในเครื่องที่ต้องมี URL นี้อาจเป็นเส้นทางแบบสัมพันธ์หรือแบบสัมบูรณ์ก็ได้ |
คำขอโดยตรงไปยังฟังก์ชัน
คุณสามารถใช้ rewrites
เพื่อรองรับฟังก์ชันจาก URL โฮสติ้งของ Firebase ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การให้บริการเนื้อหาแบบไดนามิกโดยใช้ Cloud Functions
ตัวอย่างเช่น หากต้องการกำหนดให้คำขอทั้งหมดจากเพจ /bigben
บนไซต์โฮสติ้งของคุณดำเนินการฟังก์ชัน 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)
}
} ]
}
หากละเว้น
region
จากบล็อกfunction
ของการกำหนดค่าhosting.rewrites
Firebase CLI จะพยายามตรวจจับขอบเขตโดยอัตโนมัติจากซอร์สโค้ดของฟังก์ชัน ซึ่งหากไม่ได้ระบุ จะมีค่าเริ่มต้นเป็นus-central1
หากซอร์สโค้ดของฟังก์ชันไม่พร้อมใช้งาน CLI จะพยายามตรวจจับขอบเขตจากฟังก์ชันที่ปรับใช้ หากฟังก์ชันนี้อยู่ในหลายภูมิภาค CLI กำหนดให้ต้องระบุregion
ในการกำหนดค่าhosting.rewrites
ฟีเจอร์
pinTag
ใช้ได้เฉพาะใน Cloud Functions for Firebase (รุ่นที่ 2) เท่านั้น ด้วยคุณสมบัตินี้ คุณสามารถมั่นใจได้ว่าแต่ละฟังก์ชันสำหรับการสร้างเนื้อหาไดนามิกของไซต์ของคุณจะถูกซิงค์กับทรัพยากรโฮสติ้งแบบคงที่และการกำหนดค่าโฮสติ้งของคุณ นอกจากนี้ คุณลักษณะนี้ยังช่วยให้คุณดูตัวอย่างการเขียนใหม่ของคุณไปยังฟังก์ชันต่างๆ บนช่องแสดงตัวอย่างการโฮสต์ได้หากคุณเพิ่ม
"pinTag": true
ลงในบล็อกfunction
ของการกำหนดค่าhosting.rewrites
ฟังก์ชัน "ปักหมุด" จะถูกปรับใช้พร้อมกับทรัพยากรโฮสติ้งและการกำหนดค่าแบบคงที่ของคุณ แม้ว่าจะใช้หากคุณย้อนกลับเวอร์ชันของไซต์ของคุณ ฟังก์ชัน "ปักหมุด" ก็จะถูกย้อนกลับด้วย
firebase deploy --only hosting ฟีเจอร์นี้อาศัย แท็ก Cloud Run ซึ่งมีขีดจำกัด 1,000 แท็กต่อบริการ และ 2,000 แท็กต่อภูมิภาค ซึ่งหมายความว่าหลังจากการปรับใช้หลายร้อยครั้ง ไซต์เวอร์ชันเก่าที่สุดอาจหยุดทำงาน
หลังจากเพิ่มกฎการเขียนซ้ำนี้และปรับใช้กับ Firebase (โดยใช้ firebase deploy
) คุณจะสามารถเข้าถึงฟังก์ชันของคุณผ่าน URL ต่อไปนี้:
โดเมนย่อย Firebase ของคุณ:
PROJECT_ID .web.app/bigben
และPROJECT_ID .firebaseapp.com/bigben
โดเมนแบบกำหนดเอง ที่เชื่อมต่ออยู่:
CUSTOM_DOMAIN /bigben
เมื่อเปลี่ยนเส้นทางคำขอไปยังฟังก์ชันด้วยโฮสติ้ง วิธีการร้องขอ HTTP ที่รองรับคือ GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
และ OPTIONS
ไม่รองรับวิธีการอื่นๆ เช่น REPORT
หรือ PROFIND
คำขอโดยตรงไปยังคอนเทนเนอร์ Cloud Run
คุณสามารถใช้ rewrites
เพื่อเข้าถึงคอนเทนเนอร์ Cloud Run จาก URL โฮสติ้งของ Firebase ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การให้บริการเนื้อหาแบบไดนามิกโดยใช้ 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)
}
} ]
}
ด้วยฟีเจอร์นี้ คุณสามารถมั่นใจได้ว่าการแก้ไขบริการ Cloud Run ของคุณสำหรับการสร้างเนื้อหาไดนามิกของเว็บไซต์ของคุณจะซิงค์กับทรัพยากรโฮสติ้งแบบคงที่และการกำหนดค่าโฮสติ้งของคุณ นอกจากนี้ ฟีเจอร์นี้ยังช่วยให้คุณดูตัวอย่างการเขียนซ้ำไปยัง Cloud Run บนช่องแสดงตัวอย่างโฮสติ้งได้ด้วย
หากคุณเพิ่ม
"pingTag": true
ลงในrun
block ของการกำหนดค่าhosting.rewrites
ทรัพยากรโฮสติ้งและการกำหนดค่าแบบคงที่ของคุณจะถูกปักหมุดไว้ที่บริการ Cloud Run รุ่นปรับปรุงล่าสุด ณ เวลาที่ปรับใช้ หากคุณย้อนกลับเวอร์ชันของเว็บไซต์ การแก้ไขบริการ Cloud Run ที่ "ปักหมุด" ก็จะถูกย้อนกลับด้วยฟีเจอร์นี้อาศัย แท็ก Cloud Run ซึ่งมีขีดจำกัด 1,000 แท็กต่อบริการ และ 2,000 แท็กต่อภูมิภาค ซึ่งหมายความว่าหลังจากการปรับใช้หลายร้อยครั้ง ไซต์เวอร์ชันเก่าที่สุดอาจหยุดทำงาน
หลังจากเพิ่มกฎการเขียนซ้ำนี้และปรับใช้กับ Firebase (โดยใช้ firebase deploy
) คุณจะเข้าถึงอิมเมจคอนเทนเนอร์ของคุณได้ผ่าน URL ต่อไปนี้:
โดเมนย่อย Firebase ของคุณ:
PROJECT_ID .web.app/helloworld
และPROJECT_ID .firebaseapp.com/helloworld
โดเมนแบบกำหนดเอง ที่เชื่อมต่ออยู่:
CUSTOM_DOMAIN /helloworld
เมื่อเปลี่ยนเส้นทางคำขอไปยังคอนเทนเนอร์ Cloud Run ด้วยโฮสติ้ง วิธีการร้องขอ HTTP ที่รองรับคือ GET
, POST
, HEAD
, PUT
, DELETE
, PATCH
และ OPTIONS
ไม่รองรับวิธีการอื่นๆ เช่น REPORT
หรือ PROFIND
เพื่อประสิทธิภาพที่ดีที่สุด ให้จัดตำแหน่งบริการ Cloud Run ของคุณกับโฮสติ้งโดยใช้ภูมิภาคต่อไปนี้:
-
us-west1
-
us-central1
-
us-east1
-
europe-west1
-
asia-east1
รองรับการเขียนซ้ำไปยัง Cloud Run จาก Hosting ในภูมิภาคต่อไปนี้:
-
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
สร้างโดเมนไดนามิกลิงก์แบบกำหนดเอง
คุณสามารถใช้ 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 } ] }
ระบุคำนำหน้าเส้นทางโดเมนแบบกำหนดเองเพื่อใช้สำหรับลิงก์แบบไดนามิก
"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 | เส้นทางที่คุณต้องการใช้สำหรับลิงก์แบบไดนามิก ต่างจากกฎที่เขียนเส้นทางไปยัง 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 (ย่อย-) | ส่วนหัวที่กำหนดเองที่โฮสติ้งใช้กับเส้นทางคำขอ แต่ละส่วนหัวย่อยต้องมี คู่ | ||
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 เพื่อลบเครื่องหมายทับต่อท้าย - เมื่อไม่ได้ระบุ โฮสติ้งจะใช้เครื่องหมายทับต่อท้ายสำหรับไฟล์ดัชนีไดเรกทอรีเท่านั้น (เช่น
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
หน้าวิกินี้ เป็นข้อมูลอ้างอิงที่มีรายละเอียดมากขึ้น แต่ต่อไปนี้คือคำอธิบายของตัวอย่างที่ใช้ในหน้านี้:
firebase.json
— จับคู่เฉพาะไฟล์firebase.json
ในรูทของไดเรกทอรีpublic
เท่านั้น**
— จับคู่ไฟล์หรือโฟลเดอร์ในไดเร็กทอรีย่อยที่กำหนดเอง*
— จับคู่เฉพาะไฟล์และโฟลเดอร์ในรากของไดเร็กทอรีpublic
**/.*
— จับคู่ไฟล์ใดๆ ที่ขึ้นต้นด้วย.
(โดยปกติจะเป็นไฟล์ที่ซ่อนอยู่ เช่น ในโฟลเดอร์.git
) ในไดเร็กทอรีย่อยที่กำหนดเอง**/node_modules/**
— จับคู่ไฟล์หรือโฟลเดอร์ใดๆ ในไดเร็กทอรีย่อยที่กำหนดเองของโฟลเดอร์node_modules
ซึ่งสามารถอยู่ในไดเร็กทอรีย่อยที่กำหนดเองของไดเร็กทอรีpublic
**/*.@(jpg|jpeg|gif|png)
— จับคู่ไฟล์ใดๆ ในไดเร็กทอรีย่อยที่กำหนดเองซึ่งลงท้ายด้วยรายการใดรายการหนึ่งต่อไปนี้:.jpg
,.jpeg
,.gif
หรือ.png
ตัวอย่างการกำหนดค่าโฮสติ้งแบบเต็ม
ต่อไปนี้เป็นตัวอย่างการกำหนดค่า firebase.json
แบบเต็มสำหรับโฮสติ้ง Firebase โปรดทราบว่าไฟล์ 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",
}
}