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

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

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

"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

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

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

"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
  } ]
}

"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"
  } ]
}

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

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

คุณจะใช้ 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 ของคุณต้องการสิ่งต่อไปนี้

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

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

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับ 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",

  }
}