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

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

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

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

• แสดงหน้า 404/ไม่พบหน้าที่กำหนดเอง ดูวิธีการ

• ตั้งค่า redirects สำหรับหน้าที่ย้ายหรือลบไปแล้ว ดูวิธีการ

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

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

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

  • สร้างโดเมนที่กำหนดเอง 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 จะระบุไฟล์ที่จะละเว้นเมื่อทําการนําส่ง โดยจะใช้รูปแบบได้เช่นเดียวกับที่ 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
  } ]
}

ดูตัวอย่างโดยละเอียดเพิ่มเติมสำหรับแอตทริบิวต์ 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 สำหรับ "พบ" (การเปลี่ยนเส้นทางชั่วคราว)

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

อย่างตั้งใจ

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

  }
}