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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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/ไม่พบหน้า

ไม่บังคับ
คุณสามารถแสดงข้อผิดพลาด 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
  } ]
}

"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

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

ส่งคําขอไปยังฟังก์ชันโดยตรง

คุณสามารถใช้ 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)
    }
  } ]
}

หลังจากเพิ่มกฎการเขียนใหม่นี้และนำไปใช้งานใน 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)
   }
 } ]
}

หลังจากเพิ่มกฎการเขียนใหม่นี้และทำให้ใช้งานได้ใน 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 ต้องใช้สิ่งต่อไปนี้

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

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

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

"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 ได้ที่ส่วน Hosting ซึ่งอธิบายการแสดงเนื้อหาแบบไดนามิกและการโฮสต์ไมโครเซอร์วิส นอกจากนี้ คุณยังดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัว CORS ได้ด้วย

ควบคุมส่วนขยาย .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",

  }
}