กำหนดค่าลักษณะการทำงานของโฮสติ้ง

เมื่อใช้ Firebase Hosting คุณสามารถกำหนดค่าลักษณะโฮสติ้งที่ปรับแต่งสำหรับ ไปยังเว็บไซต์ของคุณ

คุณกำหนดค่าอะไรสำหรับ Hosting ได้บ้าง

• ระบุไฟล์ในไดเรกทอรีโปรเจ็กต์ในเครื่องที่คุณต้องการทำให้ใช้งานได้ Firebase Hosting ดูวิธีการ

• แสดงหน้า 404/Not Found ที่กำหนดเอง ดูวิธีการ

• ตั้งค่า redirects สำหรับเพจที่คุณย้ายหรือลบ ดูวิธีการ

• ตั้งค่า rewrites เพื่อวัตถุประสงค์ต่อไปนี้

  • แสดงเนื้อหาเดียวกันสำหรับ URL หลายรายการ ดูวิธีการ

  • แสดงฟังก์ชันหรือเข้าถึงคอนเทนเนอร์ Cloud Run จาก Hosting URL ดูวิธี: ฟังก์ชัน หรือ คอนเทนเนอร์

  • สร้างโดเมนที่กำหนดเอง Dynamic Link ดูวิธีการ

• เพิ่ม headers เพื่อส่งข้อมูลเพิ่มเติมเกี่ยวกับคำขอหรือ การตอบสนอง เช่น วิธีที่เบราว์เซอร์ควรจัดการกับหน้าเว็บและเนื้อหาของหน้า (การตรวจสอบสิทธิ์ การแคช การเข้ารหัส ฯลฯ) ดูวิธีการ

• ตั้งค่าการปรับให้เป็นสากล (i18n) แบบใหม่เพื่อแสดงเนื้อหาเฉพาะ เกี่ยวกับค่ากำหนดภาษาและ/หรือประเทศของผู้ใช้ ดูวิธีการ (หน้าอื่น)

คุณกำหนดการกำหนดค่า Hosting ไว้ที่ใด

คุณกําหนดการกําหนดค่า Firebase Hosting ใน firebase.json Firebase สร้างไฟล์ firebase.json ที่รูทของโปรเจ็กต์โดยอัตโนมัติ เมื่อเรียกใช้เมธอด คำสั่ง firebase init

ข้อควรระวัง: หากคุณเรียกใช้ firebase init อีกครั้งและเลือก Hosting คำสั่งจะเขียนทับส่วน hosting ของไฟล์ firebase.json กลับไปเป็นการกำหนดค่าเริ่มต้น

คุณสามารถค้นหา ตัวอย่างการกำหนดค่า firebase.json แบบเต็ม (ครอบคลุมเฉพาะ Firebase Hosting) ที่ด้านล่างของหน้านี้ โปรดทราบว่า firebase.json ไฟล์อาจมี การกำหนดค่าสำหรับบริการอื่นๆ ของ Firebase

คุณสามารถตรวจสอบเนื้อหา firebase.json ที่ทำให้ใช้งานได้แล้วโดยใช้ Hosting REST API

ลําดับความสําคัญของคําตอบ Hosting รายการ

ตัวเลือกการกำหนดค่า Firebase Hosting อื่นๆ ที่อธิบายไว้ในหน้านี้ อาจทับซ้อนกันในบางครั้ง หากมีความขัดแย้ง Hosting จะกำหนดการตอบกลับโดยใช้ลําดับความสําคัญต่อไปนี้

1. เนมสเปซที่สงวนไว้ซึ่งเริ่มต้นด้วยกลุ่มเส้นทาง /__/*
2. การเปลี่ยนเส้นทางที่กำหนดค่าไว้
3. เนื้อหาแบบคงที่ที่ตรงกันทั้งหมด
4. กำหนดค่าการเขียนใหม่แล้ว
5. หน้า 404 ที่กำหนดเอง
6. หน้า 404 เริ่มต้น

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

หากคุณใช้การเขียน 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 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 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
  } ]
}

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

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

สำคัญ: Hosting ใช้การเปลี่ยนเส้นทางภายในแอตทริบิวต์ redirects กำหนดโดยกฎแรกที่มีรูปแบบ URL ตรงกับ เส้นทาง คุณจึงต้องจัดเรียงกฎภายในredirects แอตทริบิวต์

อย่างตั้งใจ

บันทึกกลุ่ม URL สำหรับการเปลี่ยนเส้นทาง

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

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

หากคุณใช้ฟิลด์ 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
  } ]
}

บันทึกกลุ่ม 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 คำขอ จะทริกเกอร์ Hosting ให้ตอบกลับราวกับว่า ได้รับ 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 Hosting จะใช้กฎการเขียนใหม่ก็ต่อเมื่อไฟล์หรือไดเรกทอรีไม่ใช้ อยู่ในเส้นทาง URL ที่ตรงกับรูปแบบ URL source หรือ regex ที่ระบุ เมื่อคำขอทริกเกอร์กฎการเขียนใหม่ เบราว์เซอร์จะแสดงผลเนื้อหาจริง ของไฟล์ destination ที่ระบุแทนการเปลี่ยนเส้นทาง HTTP

ช่อง		คำอธิบาย
rewrites
	source (แนะนำ) หรือ regex	รูปแบบ URL ที่จะทริกเกอร์หากตรงกับ URL ของคำขอเริ่มต้น Hosting เพื่อใช้การเขียนใหม่ ใช้ source เพื่อระบุ glob (แนะนำ) ใช้ regex เพื่อระบุนิพจน์ทั่วไป RE2
	destination	ไฟล์ในเครื่องที่ต้องมี URL นี้อาจเป็นเส้นทางแบบสัมพัทธ์หรือเส้นทางสัมบูรณ์ก็ได้

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

คำขอไปยังฟังก์ชันโดยตรง

คุณสามารถใช้ rewrites เพื่อแสดงฟังก์ชันจาก URL ของ Firebase Hosting ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การแสดงเนื้อหาแบบไดนามิกโดยใช้ Cloud Functions

ตัวอย่างเช่น หากต้องการส่งคำขอทั้งหมดจากหน้า /bigben ใน Hosting ที่จะเรียกใช้ฟังก์ชัน 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

หากละเว้น region จากการบล็อก function ของ hosting.rewrites Firebase CLI จะพยายามตรวจหาภูมิภาคโดยอัตโนมัติจาก ซอร์สโค้ดของฟังก์ชัน ซึ่งถ้าไม่ระบุ ค่าเริ่มต้นจะเป็น us-central1 หากซอร์สโค้ดของฟังก์ชันไม่พร้อมใช้งาน CLI จะพยายามตรวจหา ภูมิภาคจากฟังก์ชันที่ทำให้ใช้งานได้แล้ว หากฟังก์ชันอยู่ในหลายภูมิภาค CLI กำหนดให้ต้องระบุ region ใน hosting.rewrites การกำหนดค่า

อย่างไร pinTag ทำงานภายในบล็อก function

ฟีเจอร์ pinTag ใช้ได้เฉพาะใน Cloud Functions for Firebase (รุ่นที่ 2) เท่านั้น ฟีเจอร์นี้ช่วยให้มั่นใจได้ว่าฟังก์ชันแต่ละรายการในการสร้างเนื้อหาแบบไดนามิกของเว็บไซต์จะซิงค์กับทรัพยากร Hosting แบบคงที่และการกำหนดค่า Hosting อยู่เสมอ ฟีเจอร์นี้ยังช่วยให้คุณสามารถดูตัวอย่างงานที่คุณเขียนใหม่ ในฟังก์ชันในตัวอย่างช่อง Hosting

หากคุณเพิ่ม "pinTag": true ในบล็อก function ของ hosting.rewrites การกำหนดค่า แล้วตามด้วยปุ่ม "ปักหมุด" จะถูกทำให้ใช้งานได้พร้อมกับ ทรัพยากรและการกำหนดค่า Hosting รายการแม้ว่าจะทำงานอยู่ firebase deploy --only hosting หากคุณย้อนกลับ เวอร์ชันไซต์ที่ "ปักหมุดไว้" จะเปลี่ยนกลับด้วย

หมายเหตุ: หากเพิ่ม pinTag ลงในข้อความที่เขียนใหม่ที่มีอยู่ คุณต้องทำให้ข้อความที่เขียนใหม่เวอร์ชันอัปเดตใช้งานได้ในช่อง "เผยแพร่" ก่อน หลังจากติดตั้งใช้งานแล้ว คุณจะ แสดงตัวอย่างการเปลี่ยนแปลงโค้ดของฟังก์ชันใน 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

เมื่อเปลี่ยนเส้นทางคำขอไปยังฟังก์ชันด้วย Hosting เมธอดคำขอ HTTP ที่รองรับคือ GET, POST, HEAD, PUT, DELETE, PATCH และ OPTIONS ระบบไม่รองรับวิธีการอื่นๆ เช่น REPORT หรือ PROFIND

คำขอโดยตรงไปยังคอนเทนเนอร์ Cloud Run

คุณสามารถใช้ rewrites เพื่อเข้าถึงคอนเทนเนอร์ Cloud Run ได้จาก URL ของ Firebase Hosting ตัวอย่างต่อไปนี้เป็นข้อความที่ตัดตอนมาจาก การแสดงเนื้อหาแบบไดนามิกโดยใช้ Cloud Run

ตัวอย่างเช่น หากต้องการกําหนดเส้นทางคําขอทั้งหมดจากหน้า /helloworld ในเว็บไซต์ Hosting ให้ทริกเกอร์การเริ่มต้นและเรียกใช้อินสแตนซ์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)
   }
 } ]
}

วิธีที่pinTag ทำงานภายในบล็อก run

ฟีเจอร์นี้ช่วยให้คุณมั่นใจได้ว่าการแก้ไข Cloud Run บริการสำหรับการสร้างเนื้อหาแบบไดนามิกของไซต์จะซิงค์กับ ทรัพยากร Hosting แบบคงที่และการกำหนดค่า Hosting นอกจากนี้ ฟีเจอร์นี้ยังช่วยให้ คุณจะดูตัวอย่างการเขียนใหม่เป็น Cloud Run ในเวอร์ชัน Hosting ได้ แชแนล

หากคุณเพิ่ม "pinTag": true ในบล็อก run ของ hosting.rewrites config ทรัพยากรและการกำหนดค่าแบบคงที่ของ Hosting จะปักหมุดไว้ที่ การแก้ไขล่าสุดของบริการ 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 ด้วย Hosting เมธอดคำขอ HTTP ที่รองรับ ได้แก่ GET, POST, HEAD, PUT, DELETE PATCH และ OPTIONS วิธีการอื่นๆ เช่น REPORT หรือ PROFIND ไม่ใช่วิธีการอื่น ที่รองรับ

เพื่อประสิทธิภาพที่ดีที่สุด โปรดย้ายบริการ Cloud Run ของคุณกับ Hosting โดยใช้ภูมิภาคต่อไปนี้

• 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

สร้างโดเมนที่กำหนดเอง Dynamic Links

คุณใช้ rewrites เพื่อสร้างโดเมน Dynamic Links ที่กำหนดเองได้ ไปที่ Dynamic Links เพื่อดูข้อมูลโดยละเอียดเกี่ยวกับ การตั้งค่าโดเมนที่กำหนดเองสำหรับ 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
    } ]
  }

การกำหนดค่า Dynamic Links ในไฟล์ firebase.json จำเป็นต้องใช้สิ่งต่อไปนี้

ช่อง		คำอธิบาย
appAssociation		ต้องตั้งค่าเป็น AUTO ถ้าคุณไม่ได้รวมแอตทริบิวต์นี้ไว้ในการกำหนดค่าของคุณ ค่าเริ่มต้นสำหรับ appAssociation คือ AUTO การตั้งค่าแอตทริบิวต์นี้เป็น AUTO จะทำให้ Hosting สามารถสร้างไฟล์ assetlinks.json และ apple-app-site-association แบบไดนามิกเมื่อมีการขอ
rewrites
	source	เส้นทางที่คุณต้องการใช้สำหรับ Dynamic Links เขียนกฎ Dynamic Links ใหม่ ซึ่งต่างจากกฎที่เขียนเส้นทางไปยัง URL ใหม่ ต้องไม่มีนิพจน์ทั่วไป
	dynamicLinks	ต้องตั้งค่าเป็น true

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

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

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

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

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

ระบุส่วนหัวการตอบกลับเฉพาะไฟล์แบบกำหนดเองด้วยการสร้างแอตทริบิวต์ headers ที่มีอาร์เรย์ของออบเจ็กต์ส่วนหัว ระบุรูปแบบ URL ในแต่ละออบเจ็กต์ ที่หากตรงกับเส้นทาง URL คำขอ จะทริกเกอร์ Hosting ให้ใช้ ส่วนหัวการตอบกลับแบบกำหนดเองที่ระบุ

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

หมายเหตุ: การจับคู่รูปแบบ URL สําหรับส่วนหัวที่กําหนดเองจะทําก่อนที่มีการใช้กฎการเขียนใหม่

ดูข้อมูลเพิ่มเติมเกี่ยวกับ Cache-Control ได้ใน Hosting ที่อธิบายการแสดงเนื้อหาแบบไดนามิกและโฮสติ้ง Microservice คุณยังดูข้อมูลเพิ่มเติมเกี่ยวกับ ส่วนหัว CORS

สำคัญ: Firebase Hosting จะเขียนทับการกำหนดค่า Strict-Transport-Security ในโดเมนย่อย Hosting เริ่มต้น (เช่น *.web.app) อย่างไรก็ตาม โดเมนที่กำหนดเองที่เชื่อมต่อจะแสดงค่าที่กำหนดค่าไว้

ควบคุมส่วนขยาย .html รายการ

ไม่บังคับ
แอตทริบิวต์ cleanUrls ช่วยให้คุณควบคุมได้ว่า URL ควรมีนามสกุล .html หรือไม่

เมื่อ true Hosting จะนํานามสกุล .html ออกจาก URL ของไฟล์ที่อัปโหลดโดยอัตโนมัติ หากมีการเพิ่มนามสกุล .html ในคําขอ Hosting จะทํา 301Redirect ไปยังเส้นทางเดียวกันแต่นํานามสกุล .html ออก

วิธีควบคุมการรวม .html ไว้ใน URL โดยการรวม แอตทริบิวต์ cleanUrls:

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

ควบคุมเครื่องหมายทับต่อท้าย

ไม่บังคับ
แอตทริบิวต์ trailingSlash ช่วยให้คุณควบคุมได้ว่า URL ของเนื้อหาแบบคงที่ควรมีเครื่องหมายทับต่อท้ายหรือไม่

• เมื่อ true นั้น Hosting จะเปลี่ยนเส้นทาง URL เพื่อเพิ่มเครื่องหมายทับปิดท้าย
• เมื่อ false Hosting จะเปลี่ยนเส้นทาง URL เพื่อนำเครื่องหมายทับปิดท้ายออก
• เมื่อไม่ระบุ Hosting จะใช้เฉพาะเครื่องหมายทับปิดท้ายสำหรับดัชนีไดเรกทอรี ไฟล์ (เช่น about/index.html)

วิธีควบคุมเครื่องหมายทับท้ายด้วยการใส่แอตทริบิวต์ trailingSlash มีดังนี้

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

แอตทริบิวต์ trailingSlash ไม่มีผลกับการเขียนใหม่สำหรับเนื้อหาแบบไดนามิก ให้บริการโดย Cloud Functions หรือ Cloud Run

การจับคู่รูปแบบ Glob

ตัวเลือกการกำหนดค่า Firebase Hosting ใช้ประโยชน์จาก การจับคู่รูปแบบ 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

ตัวอย่างการกำหนดค่า Hosting แบบเต็ม

ต่อไปนี้คือตัวอย่างการกําหนดค่า 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",

  }
}