หน้านี้ได้รับการแปลโดย Cloud Translation API

กำหนดค่าพฤติกรรมการโฮสต์

ด้วย Firebase Hosting คุณสามารถกำหนดค่าพฤติกรรมการโฮสต์แบบกำหนดเองสำหรับคำขอไปยังไซต์ของคุณได้

คุณสามารถกำหนดค่าอะไรสำหรับโฮสติ้งได้บ้าง

ระบุไฟล์ในไดเร็กทอรีโปรเจ็กต์ในเครื่องที่คุณต้องการปรับใช้กับ Firebase Hosting เรียนรู้วิธีการ
แสดงหน้า 404/Not Found ที่กำหนดเอง เรียนรู้วิธีการ
ตั้งค่า 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

ลำดับความสำคัญของการตอบกลับโฮสติ้ง

ตัวเลือกการกำหนดค่าโฮสติ้ง 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 ค่าเริ่มต้นคือไดเร็กทอรีชื่อ 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 คำขอ จะทริกเกอร์โฮสติ้งให้ตอบสนองด้วยการเปลี่ยนเส้นทางไปยัง 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

"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 จะส่งการตอบสนองการเปลี่ยนเส้นทาง HTTPS เพื่อบอกให้เบราว์เซอร์ส่งคำขอใหม่ที่ URL destination

สนาม		คำอธิบาย
`redirects`
	`source` (แนะนำ) หรือ `regex`	รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น ทริกเกอร์โฮสติ้งเพื่อใช้การเปลี่ยนเส้นทาง ใช้ `source` เพื่อระบุ glob (แนะนำ) ใช้ `regex` เพื่อระบุ นิพจน์ทั่วไปของ RE2
	`destination`	URL แบบคงที่ซึ่งเบราว์เซอร์ควรส่งคำขอใหม่ URL นี้อาจเป็นเส้นทางสัมพัทธ์หรือเส้นทางสัมบูรณ์ก็ได้
	`type`	รหัสตอบกลับ HTTPS ใช้ประเภท `301` สำหรับ 'ย้ายอย่างถาวร' ใช้ประเภท `302` สำหรับ 'พบ' (เปลี่ยนเส้นทางชั่วคราว)

จับภาพส่วน URL สำหรับการเปลี่ยนเส้นทาง

ไม่จำเป็น
บางครั้ง คุณอาจต้องบันทึกส่วนเฉพาะของรูปแบบ URL ของกฎการเปลี่ยนเส้นทาง (ค่า source หรือค่า regex ) จากนั้นใช้ส่วนเหล่านี้ซ้ำในเส้นทาง destination ของกฎ

จับกลุ่ม URL เมื่อใช้ทรงกลม

หากคุณใช้ฟิลด์ source (นั่นคือ การระบุลูกโลกสำหรับรูปแบบ 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
  } ]
}

จับกลุ่ม URL เมื่อใช้นิพจน์ทั่วไป RE2

หากคุณใช้ช่อง 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 ที่ตรงกับรูปแบบ 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

"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 คำขอเริ่มต้น ทริกเกอร์โฮสติ้งเพื่อใช้การเขียนซ้ำ ใช้ `source` เพื่อระบุ glob (แนะนำ) ใช้ `regex` เพื่อระบุ นิพจน์ทั่วไปของ RE2
	`destination`	ไฟล์ในเครื่องที่ต้องมี URL นี้อาจเป็นเส้นทางสัมพัทธ์หรือเส้นทางสัมบูรณ์ก็ได้

rewrites

source (แนะนำ)
หรือ regex

รูปแบบ URL ที่หากตรงกับ URL คำขอเริ่มต้น ทริกเกอร์โฮสติ้งเพื่อใช้การเขียนซ้ำ

ใช้ source เพื่อระบุ glob (แนะนำ)
ใช้ regex เพื่อระบุ นิพจน์ทั่วไปของ RE2

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": "bigben",
    "region": "us-central1"  // 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 จาก 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 ด้วยโฮสติ้ง วิธีการขอ 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

สร้างไดนามิกลิงก์ของโดเมนที่กำหนดเอง

คุณสามารถใช้การ 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`		ต้องตั้งค่าเป็น `AUTO` หากคุณไม่ได้รวมแอตทริบิวต์นี้ในการกำหนดค่า ค่าเริ่มต้นสำหรับ `appAssociation` คือ `AUTO` เมื่อตั้งค่าแอตทริบิวต์นี้เป็น `AUTO` โฮสติ้งสามารถสร้าง `assetlinks.json` และ `apple-app-site-association` แบบไดนามิกเมื่อได้รับการร้องขอ
`rewrites`
	`source`	เส้นทางที่คุณต้องการใช้สำหรับลิงก์แบบไดนามิก ซึ่งแตกต่างจากกฎที่เขียนเส้นทางไปยัง URL ใหม่ กฎการเขียนใหม่สำหรับลิงก์แบบไดนามิกต้องไม่มีนิพจน์ทั่วไป
	`dynamicLinks`	ต้องตั้งค่า `true`

ข้อ สำคัญ : สำหรับไดนามิกลิงก์ ให้ระวัง ลำดับความสำคัญของการโฮสต์เป็น พิเศษ

ตรวจสอบให้แน่ใจว่าคำนำหน้า URL ลิงก์แบบไดนามิกของคุณไม่ขัดแย้งกับการกำหนดค่าการโฮสต์ที่มีลำดับความสำคัญสูงกว่า (เช่น เนื้อหาคงที่ที่โฮสต์จะมีลำดับความสำคัญมากกว่าการเขียนซ้ำเสมอ)
ภายในแอตทริบิวต์การ redirects และการ rewrites แต่ละรายการ โฮสติ้งจะใช้การเปลี่ยนเส้นทางหรือการเขียนซ้ำที่กำหนดโดยกฎข้อ แรก ด้วยรูปแบบ URL ที่ตรงกับเส้นทางที่ร้องขอ ดังนั้น คุณต้องจงใจจัดลำดับกฎภายในแอตทริบิวต์การ redirects และการ rewrites แต่ละรายการ

สำหรับข้อมูลโดยละเอียด โปรดดู เอกสารประกอบของ Dynamic Links

กำหนดค่าส่วนหัว

ไม่จำเป็น
ส่วนหัวอนุญาตให้ไคลเอนต์และเซิร์ฟเวอร์ส่งข้อมูลเพิ่มเติมพร้อมกับคำขอหรือการตอบกลับ ส่วนหัวบางชุดอาจส่งผลต่อวิธีที่เบราว์เซอร์จัดการกับหน้าและเนื้อหา รวมถึงการควบคุมการเข้าถึง การรับรองความถูกต้อง การแคช และการเข้ารหัส

ระบุส่วนหัวการตอบสนองเฉพาะไฟล์ที่กำหนดเองโดยสร้างแอตทริบิวต์ 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

"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 คำขอเริ่มต้น ทริกเกอร์โฮสติ้งเพื่อใช้ส่วนหัวที่กำหนดเอง ใช้ `source` เพื่อระบุ glob (แนะนำ) ใช้ `regex` เพื่อระบุ นิพจน์ทั่วไปของ RE2 หากต้องการสร้างส่วนหัวให้ตรงกับ หน้า 404 ที่กำหนดเอง ให้ใช้ `404.html` เป็นค่า `source` หรือค่า `regex`
	อาร์เรย์ของ `headers` (ย่อย)		ส่วนหัวที่กำหนดเองที่โฮสติ้งใช้กับเส้นทางคำขอ ส่วนหัวย่อยแต่ละรายการต้องมี คู่ `key` และ `value` (ดูสองแถวถัดไป)
		`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

การจับคู่รูปแบบลูกโลก

ตัวเลือกการกำหนดค่าโฮสติ้งของ 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",

  }
}