โฮสติ้งของ Firebase ช่วยให้คุณกำหนดค่าลักษณะโฮสติ้งที่กำหนดเองสำหรับคำขอไปยังเว็บไซต์ได้
คุณกำหนดค่าอะไรได้บ้างสำหรับโฮสติ้ง
ระบุไฟล์ในไดเรกทอรีโปรเจ็กต์ในเครื่องที่ต้องการทำให้ใช้งานได้กับโฮสติ้งของ 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 ใหม่ ลำดับความสำคัญของการจับคู่ที่ตรงกันทั้งหมดและ 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/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
} ]
}
แอตทริบิวต์ redirects
มีอาร์เรย์ของกฎการเปลี่ยนเส้นทาง ซึ่งแต่ละกฎต้องมีช่องในตารางด้านล่าง
โฮสติ้งของ Firebase จะเปรียบเทียบค่า source
หรือ regex
กับเส้นทาง URL ทั้งหมดเมื่อเริ่มต้นคำขอทุกรายการ (ก่อนที่เบราว์เซอร์จะพิจารณาว่ามีไฟล์หรือโฟลเดอร์อยู่ในเส้นทางนั้นหรือไม่) หากพบรายการที่ตรงกัน เซิร์ฟเวอร์ต้นทางโฮสติ้งของ Firebase จะส่งการตอบกลับการเปลี่ยนเส้นทาง HTTPS เพื่อบอกเบราว์เซอร์ให้ส่งคำขอใหม่ที่ URL destination
ฟิลด์ | คำอธิบาย | |
---|---|---|
redirects |
||
source (แนะนำ) หรือ regex
|
รูปแบบ URL ที่หากตรงกับ URL ของคำขอเริ่มต้น ระบบจะทริกเกอร์โฮสติ้งให้ใช้การเปลี่ยนเส้นทาง
|
|
destination |
URL ที่มีเนื้อหาคงที่ซึ่งเบราว์เซอร์ควรส่งคำขอใหม่ URL นี้อาจเป็นเส้นทางแบบสัมพัทธ์หรือเส้นทางสัมบูรณ์ก็ได้ |
|
type |
โค้ดตอบกลับ HTTPS
|
บันทึกกลุ่ม URL สำหรับการเปลี่ยนเส้นทาง
ไม่บังคับ
บางครั้งคุณอาจต้องบันทึกกลุ่มที่เจาะจงของรูปแบบ URL ของกฎการเปลี่ยนเส้นทาง (ค่า source
หรือ regex
) จากนั้นจึงใช้กลุ่มเหล่านี้ซ้ำในเส้นทาง destination
ของกฎ
กำหนดค่าการเขียนใหม่
ไม่บังคับ
ใช้การเขียนซ้ำเพื่อแสดงเนื้อหาเดียวกันสำหรับ URL หลายรายการ การเขียนใหม่มีประโยชน์เป็นพิเศษกับการจับคู่รูปแบบ เนื่องจากคุณจะยอมรับ URL ใดก็ได้ที่ตรงกับรูปแบบ และให้โค้ดฝั่งไคลเอ็นต์เป็นผู้กำหนดว่าจะแสดงอะไร
คุณยังใช้การเขียนใหม่เพื่อรองรับแอปที่ใช้ HTML5 pushState สำหรับการไปยังส่วนต่างๆ ได้ด้วย เมื่อเบราว์เซอร์พยายามเปิดเส้นทาง URL ที่ตรงกับรูปแบบ URL source
หรือ 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"
} ]
}
แอตทริบิวต์ rewrites
มีอาร์เรย์ของกฎการเขียนใหม่ ซึ่งแต่ละกฎต้องมีช่องในตารางด้านล่าง
โฮสติ้งของ Firebase จะใช้กฎการเขียนใหม่ก็ต่อเมื่อไฟล์หรือไดเรกทอรีไม่มีอยู่ในเส้นทาง URL ที่ตรงกับรูปแบบ URL source
หรือ 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)
}
} ]
}
หลังจากเพิ่มกฎการเขียนใหม่และทำให้ใช้งานได้กับ 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)
}
} ]
}
หลังจากเพิ่มกฎการเขียนใหม่และทำให้ใช้งานได้กับ 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 ในภูมิภาคต่อไปนี้
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
เพื่อสร้างลิงก์แบบไดนามิกของโดเมนที่กำหนดเอง โปรดดูเอกสารประกอบเกี่ยวกับลิงก์แบบไดนามิกเพื่อดูข้อมูลอย่างละเอียดเกี่ยวกับการตั้งค่าโดเมนที่กำหนดเองสำหรับลิงก์แบบไดนามิก
ใช้โดเมนที่กำหนดเองกับลิงก์แบบไดนามิกเท่านั้น
"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": "*"
} ]
} ]
}
แอตทริบิวต์ headers
มีอาร์เรย์ของคำจำกัดความ โดยที่คำจำกัดความแต่ละรายการต้องมีช่องในตารางด้านล่าง
ฟิลด์ | คำอธิบาย | ||
---|---|---|---|
headers |
|||
source (แนะนำ) หรือ regex
|
รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น โฮสติ้งให้ใช้ส่วนหัวที่กำหนดเอง
หากต้องการสร้างส่วนหัวเพื่อจับคู่กับหน้า 404 ที่กำหนดเอง ให้ใช้ |
||
อาร์เรย์ของ (ย่อย)headers |
ส่วนหัวที่กำหนดเองซึ่งโฮสติ้งใช้กับเส้นทางคำขอ ส่วนหัวย่อยแต่ละรายการต้องมีคู่ |
||
key |
ชื่อของส่วนหัว เช่น Cache-Control |
||
value |
ค่าของส่วนหัว เช่น max-age=7200 |
ดูข้อมูลเพิ่มเติมเกี่ยวกับ Cache-Control
ได้ในส่วนโฮสติ้งที่อธิบายการแสดงเนื้อหาแบบไดนามิกและโฮสติ้ง Microservice นอกจากนี้คุณยังดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัว 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",
}
}