ข้อมูลเบื้องต้น
Service Worker ช่วยให้นักพัฒนาเว็บสามารถตอบสนองต่อคำขอเครือข่ายที่ส่งโดยเว็บแอปพลิเคชันของตนได้ ซึ่งช่วยให้แอปพลิเคชันทำงานต่อไปได้แม้ว่าจะออฟไลน์อยู่ รับมือกับ Wi-Fi ที่ไม่เสถียร และใช้งานการโต้ตอบกับแคชที่ซับซ้อน เช่น stale-while-revalidate แต่ที่ผ่านมา Service Worker เชื่อมโยงกับต้นทางที่เฉพาะเจาะจง ในฐานะเจ้าของเว็บแอป คุณมีหน้าที่เขียนและติดตั้งใช้งาน Service Worker เพื่อขัดขวางคําขอเครือข่ายทั้งหมดที่เว็บแอปของคุณส่ง ในโมเดลดังกล่าว แต่ละ Service Worker มีหน้าที่รับผิดชอบในการจัดการคำขอข้ามแหล่งที่มา เช่น คำขอไปยัง API ของบุคคลที่สามหรือคำขอสำหรับแบบอักษรเว็บ
จะเกิดอะไรขึ้นหากผู้ให้บริการ API, เว็บฟอนต์ หรือบริการอื่นๆ ที่มักใช้กันทั่วไปซึ่งเป็นบุคคลที่สามมีสิทธิ์ในการติดตั้งใช้งาน Service Worker ของตนเองซึ่งมีโอกาสจัดการคําขอที่ส่งมาจากต้นทางอื่นไปยังต้นทางของตน ผู้ให้บริการสามารถใช้ตรรกะการทํางานของเครือข่ายที่กําหนดเอง และใช้ประโยชน์จากอินสแตนซ์แคชที่เชื่อถือได้เพียงรายการเดียวสําหรับจัดเก็บคําตอบ ตอนนี้ การดึงข้อมูลจากภายนอกช่วยให้การติดตั้งใช้งาน Service Worker ประเภทของบุคคลที่สามนั้นกลายเป็นจริง
การใช้ Service Worker ที่ใช้การดึงข้อมูลภายนอกจะเหมาะกับผู้ให้บริการบริการที่เข้าถึงผ่านคําขอ HTTPS จากเบราว์เซอร์ ลองนึกถึงสถานการณ์ที่คุณให้บริการเวอร์ชันที่ไม่ขึ้นอยู่กับเครือข่าย ซึ่งเบราว์เซอร์สามารถใช้ประโยชน์จากแคชทรัพยากรทั่วไปได้ บริการที่อาจได้รับประโยชน์จากฟีเจอร์นี้รวมถึงแต่ไม่จำกัดเพียงบริการต่อไปนี้
- ผู้ให้บริการ API ที่มีอินเทอร์เฟซ RESTful
- ผู้ให้บริการแบบอักษรเว็บ
- ผู้ให้บริการวิเคราะห์
- ผู้ให้บริการโฮสต์รูปภาพ
- เครือข่ายนำส่งข้อมูลทั่วไป
ตัวอย่างเช่น สมมติว่าคุณเป็นผู้ให้บริการข้อมูลวิเคราะห์ การใช้แรงงานบริการการดึงข้อมูลต่างประเทศช่วยให้มั่นใจได้ว่าคําขอทั้งหมดที่ส่งไปยังบริการของคุณซึ่งดำเนินการไม่สำเร็จขณะที่ผู้ใช้ออฟไลน์จะอยู่ในคิวและเล่นซ้ำเมื่อการเชื่อมต่อกลับมาทำงานอีกครั้ง แม้ว่าไคลเอ็นต์ของบริการจะใช้ลักษณะการทำงานที่คล้ายกันผ่าน Service Worker ของบุคคลที่หนึ่งได้ แต่การกำหนดให้ไคลเอ็นต์แต่ละรายเขียนตรรกะเฉพาะสำหรับบริการของคุณนั้นปรับขนาดได้ไม่ดีเท่ากับการใช้บริการ Service Worker สำหรับการดึงข้อมูลภายนอกที่แชร์ซึ่งคุณติดตั้งใช้งาน
ข้อกำหนดเบื้องต้น
โทเค็นช่วงทดลองใช้จากต้นทาง
การดึงข้อมูลจากต่างประเทศยังถือว่าอยู่ในขั้นทดลอง เราได้ติดตั้งใช้งานการออกแบบนี้ใน Chrome 54 เป็นการทดลองใช้แหล่งที่มาเพื่อไม่ให้มีการใช้งานก่อนเวลาอันควรก่อนที่ผู้ให้บริการเบราว์เซอร์จะระบุและยอมรับการออกแบบนี้อย่างสมบูรณ์ ตราบใดที่การดึงข้อมูลจากภายนอกยังอยู่ในขั้นทดลอง หากต้องการใช้ฟีเจอร์ใหม่นี้กับบริการที่คุณโฮสต์ คุณจะต้องขอโทเค็นที่มีขอบเขตไปยังต้นทางที่เฉพาะเจาะจงของบริการ คุณควรใส่โทเค็นเป็นส่วนหัวการตอบกลับ HTTP ในคําขอข้ามโดเมนทั้งหมดสําหรับทรัพยากรที่คุณต้องการจัดการผ่านการดึงข้อมูลภายนอก รวมถึงในการตอบกลับสําหรับทรัพยากร JavaScript ของ Service Worker ดังนี้
Origin-Trial: token_obtained_from_signup
ช่วงทดลองใช้จะสิ้นสุดในเดือนมีนาคม 2017 เมื่อถึงเวลานั้น เราคาดว่าจะพบการเปลี่ยนแปลงที่จำเป็นเพื่อทำให้ฟีเจอร์นี้ทำงานได้อย่างเสถียร และ (หวังว่า) จะเปิดใช้ฟีเจอร์นี้โดยค่าเริ่มต้น หากไม่ได้เปิดใช้การดึงข้อมูลจากต่างประเทศโดยค่าเริ่มต้นภายในเวลาดังกล่าว ฟังก์ชันการทำงานที่เชื่อมโยงกับโทเค็นช่วงทดลองใช้ของต้นทางที่มีอยู่จะหยุดทำงาน
หากต้องการทดลองใช้การดึงข้อมูลจากต่างประเทศก่อนลงทะเบียนรับโทเค็นทดลองใช้อย่างเป็นทางการของ Origin คุณสามารถข้ามข้อกำหนดใน Chrome สำหรับคอมพิวเตอร์เครื่องที่ใช้อยู่ได้โดยไปที่ chrome://flags/#enable-experimental-web-platform-features
แล้วเปิดใช้ Flag "ฟีเจอร์แพลตฟอร์มเว็บเวอร์ชันทดลอง" โปรดทราบว่าต้องดำเนินการนี้ในทุกอินสแตนซ์ของ Chrome ที่ต้องการใช้ในการทดสอบในเครื่อง แต่หากใช้โทเค็นการทดลองใช้เวอร์ชันที่ใช้งานจริง ฟีเจอร์นี้จะพร้อมให้บริการแก่ผู้ใช้ Chrome ทุกคน
HTTPS
เช่นเดียวกับการติดตั้งใช้งาน Service Worker ทั้งหมด เว็บเซิร์ฟเวอร์ที่คุณใช้เพื่อแสดงทั้งทรัพยากรและสคริปต์ Service Worker ต้องเข้าถึงได้ผ่าน HTTPS นอกจากนี้ การดักรับการดึงข้อมูลภายนอกจะมีผลกับคำขอที่มาจากหน้าเว็บที่โฮสต์ในต้นทางที่ปลอดภัยเท่านั้น ดังนั้นไคลเอ็นต์ของบริการจึงต้องใช้ HTTPS เพื่อใช้ประโยชน์จากการติดตั้งใช้งานการดึงข้อมูลภายนอก
การใช้การดึงข้อมูลจากต่างประเทศ
เมื่อเตรียมความพร้อมเบื้องต้นเสร็จแล้ว เรามาเจาะลึกรายละเอียดทางเทคนิคที่จําเป็นในการทำให้เวิร์กเกอร์บริการดึงข้อมูลต่างประเทศพร้อมใช้งานกัน
การลงทะเบียน Service Worker
ปัญหาแรกที่คุณอาจพบคือวิธีลงทะเบียน Service Worker หากคุณเคยทํางานกับ Service Worker มาก่อน คุณอาจคุ้นเคยกับสิ่งต่อไปนี้
// You can't do this!
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('service-worker.js');
}
โค้ด JavaScript สำหรับการลงทะเบียน Service Worker ของบุคคลที่หนึ่งนี้เหมาะสําหรับบริบทของเว็บแอป ซึ่งทริกเกอร์โดยผู้ใช้ที่ไปยัง URL ที่คุณควบคุม แต่นี่ไม่ใช่แนวทางที่ใช้งานได้จริงในการลงทะเบียน Service Worker ของบุคคลที่สาม เมื่อการโต้ตอบเพียงอย่างเดียวที่เบราว์เซอร์จะมีกับเซิร์ฟเวอร์ของคุณคือการขอทรัพยากรย่อยที่เฉพาะเจาะจง ไม่ใช่การไปยังส่วนต่างๆ อย่างเต็มรูปแบบ หากเบราว์เซอร์ขอรูปภาพจากเซิร์ฟเวอร์ CDN ที่คุณดูแล คุณไม่สามารถใส่ข้อมูลโค้ด JavaScript นั้นไว้ข้างหน้าคำตอบและคาดหวังว่าระบบจะเรียกใช้ ต้องใช้วิธีการจดทะเบียน Service Worker แบบอื่นนอกบริบทการเรียกใช้ JavaScript ปกติ
โซลูชันนี้อยู่ในรูปแบบส่วนหัว HTTP ที่เซิร์ฟเวอร์ของคุณรวมไว้ในการตอบกลับได้
Link: </service-worker.js>; rel="serviceworker"; scope="/"
เรามาแยกส่วนหัวตัวอย่างนี้ออกเป็นคอมโพเนนต์ต่างๆ ซึ่งแต่ละรายการคั่นด้วยอักขระ ;
</service-worker.js>
เป็นค่าที่ต้องระบุและใช้เพื่อระบุเส้นทางไปยังไฟล์ Service Worker (แทนที่/service-worker.js
ด้วยเส้นทางที่เหมาะสมไปยังสคริปต์) ซึ่งสอดคล้องกับสตริงscriptURL
โดยตรง ซึ่งจะส่งผ่านเป็นพารามิเตอร์แรกไปยังnavigator.serviceWorker.register()
ค่าต้องอยู่ในอักขระ<>
(ตามที่ข้อกำหนดส่วนหัวLink
กำหนด) และหากระบุ URL แบบสัมพัทธ์แทน URL แบบสัมบูรณ์ ระบบจะตีความว่า URL นั้นสัมพันธ์กับตำแหน่งของคำตอบ- นอกจากนี้ คุณยังต้องใช้
rel="serviceworker"
ด้วย และควรรวมไว้โดยไม่จำเป็นต้องปรับแต่ง scope=/
คือการประกาศขอบเขตที่ไม่บังคับ ซึ่งเทียบเท่ากับสตริงoptions.scope
ที่คุณส่งเป็นพารามิเตอร์ที่ 2 ให้กับnavigator.serviceWorker.register()
ได้ สําหรับกรณีการใช้งานหลายรายการ คุณจะใช้ขอบเขตเริ่มต้นได้ ดังนั้นไม่ต้องระบุขอบเขตนี้ เว้นแต่คุณจะรู้ว่าจําเป็นต้องใช้ ข้อจํากัดเดียวกันเกี่ยวกับขอบเขตสูงสุดที่อนุญาต รวมถึงความสามารถในการผ่อนคลายข้อจํากัดเหล่านั้นผ่านส่วนหัวService-Worker-Allowed
จะมีผลกับการลงทะเบียนส่วนหัวLink
เช่นเดียวกับการลงทะเบียน Service Worker แบบ "ดั้งเดิม" การใช้ส่วนหัว Link
จะติดตั้ง Service Worker ที่จะใช้สําหรับคําขอถัดไปที่ส่งไปยังขอบเขตที่ลงทะเบียน ระบบจะใช้เนื้อหาของการตอบกลับที่มีส่วนหัวพิเศษตามที่เป็นอยู่ และพร้อมใช้งานในหน้าเว็บทันทีโดยไม่ต้องรอให้เจ้าหน้าที่บริการต่างประเทศติดตั้งเสร็จ
โปรดทราบว่าปัจจุบันการดึงข้อมูลจากภายนอกมีการใช้งานเป็นช่วงทดลองใช้จากต้นทาง คุณจึงต้องใส่ส่วนหัว Origin-Trial
ที่ถูกต้องไว้ด้วยนอกเหนือจากส่วนหัวการตอบกลับของลิงก์ ชุดส่วนหัวการตอบกลับขั้นต่ำที่จะเพิ่มเพื่อลงทะเบียนผู้ปฏิบัติงานบริการดึงข้อมูลต่างประเทศคือ
Link: </service-worker.js>; rel="serviceworker"
Origin-Trial: token_obtained_from_signup
การแก้ไขข้อบกพร่องการลงทะเบียน
ในระหว่างการพัฒนา คุณอาจต้องตรวจสอบว่าติดตั้งและประมวลผลคําขอของ Wapper บริการดึงข้อมูลต่างประเทศอย่างถูกต้อง คุณสามารถตรวจสอบสิ่งต่างๆ ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome เพื่อยืนยันว่าทุกอย่างทำงานได้ตามที่คาดไว้
มีการส่งส่วนหัวการตอบกลับที่เหมาะสมหรือไม่
หากต้องการลงทะเบียนเวิร์กเกอร์บริการดึงข้อมูลต่างประเทศ คุณต้องตั้งค่าส่วนหัว Link ในการตอบกลับทรัพยากรที่โฮสต์ในโดเมนของคุณ ตามที่อธิบายไว้ก่อนหน้านี้ในโพสต์นี้ ในช่วงทดลองใช้จากต้นทาง และสมมติว่าคุณไม่ได้ตั้งค่า chrome://flags/#enable-experimental-web-platform-features
คุณจะต้องตั้งค่าส่วนหัวการตอบกลับ Origin-Trial
ด้วย คุณสามารถยืนยันว่าเว็บเซิร์ฟเวอร์กําลังตั้งค่าส่วนหัวเหล่านั้นได้โดยดูที่รายการในแผงเครือข่ายของเครื่องมือสําหรับนักพัฒนาเว็บ

Service Worker ของ Foreign Fetch ลงทะเบียนอย่างถูกต้องหรือไม่
นอกจากนี้ คุณยังยืนยันการลงทะเบียน Service Worker ที่เกี่ยวข้อง รวมถึงขอบเขตของ Service Worker ได้โดยดูรายการ Service Worker ทั้งหมดในแผงแอปพลิเคชันของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ อย่าลืมเลือกตัวเลือก "แสดงทั้งหมด" เนื่องจากโดยค่าเริ่มต้น คุณจะเห็นเฉพาะ Service Worker ของต้นทางปัจจุบัน

เครื่องจัดการเหตุการณ์การติดตั้ง
เมื่อลงทะเบียน Service Worker ของบุคคลที่สามแล้ว Service Worker ดังกล่าวจะมีโอกาสตอบสนองต่อเหตุการณ์ install
และ activate
เช่นเดียวกับ Service Worker อื่นๆ ซึ่งสามารถใช้ประโยชน์จากเหตุการณ์เหล่านั้นได้ เช่น การสร้างแคชด้วยทรัพยากรที่จําเป็นในระหว่างเหตุการณ์ install
หรือตัดแคชที่ล้าสมัยในเหตุการณ์ activate
นอกจากกิจกรรมการแคชเหตุการณ์ install
ปกติแล้ว ยังมีขั้นตอนเพิ่มเติมที่จําเป็นใน install
event handler ของ Service Worker ของบุคคลที่สาม โค้ดของคุณต้องเรียกใช้ registerForeignFetch()
ดังตัวอย่างต่อไปนี้
self.addEventListener('install', event => {
event.registerForeignFetch({
scopes: [self.registration.scope], // or some sub-scope
origins: ['*'] // or ['https://example.com']
});
});
การกำหนดค่ามี 2 ตัวเลือก ซึ่งต้องกำหนดค่าทั้ง 2 ตัวเลือก
scopes
จะรับอาร์เรย์สตริงอย่างน้อย 1 รายการ โดยแต่ละรายการแสดงขอบเขตของคําขอที่จะทริกเกอร์เหตุการณ์foreignfetch
แต่เดี๋ยวก่อน คุณอาจกำลังคิดว่าฉันได้กําหนดขอบเขตไว้แล้วระหว่างการลงทะเบียน Service Worker ถูกต้อง ขอบเขตโดยรวมดังกล่าวยังคงเกี่ยวข้องอยู่ แต่ละขอบเขตที่คุณระบุที่นี่ต้องเท่ากับหรือเป็นขอบเขตย่อยของขอบเขตโดยรวมของ Service Worker ข้อจํากัดการกําหนดขอบเขตเพิ่มเติมที่นี่ช่วยให้คุณติดตั้งใช้งาน Service Worker อเนกประสงค์ที่จัดการทั้งเหตุการณ์fetch
ของบุคคลที่หนึ่ง (สําหรับคําขอที่ส่งจากเว็บไซต์ของคุณเอง) และเหตุการณ์foreignfetch
ของบุคคลที่สาม (สําหรับคําขอที่ส่งจากโดเมนอื่นๆ) ได้ และระบุให้ชัดเจนว่าควรทริกเกอร์foreignfetch
เฉพาะชุดย่อยของขอบเขตที่กว้างขึ้น ในทางปฏิบัติ หากคุณกำลังติดตั้งใช้งาน Service Worker ที่จัดการเฉพาะเหตุการณ์foreignfetch
ของบุคคลที่สาม คุณก็ควรใช้ขอบเขตที่ชัดเจนเพียงขอบเขตเดียวซึ่งเท่ากับขอบเขตโดยรวมของ Service Worker ตัวอย่างข้างต้นจะทําเช่นนั้นโดยใช้ค่าself.registration.scope
origins
ยังรับอาร์เรย์สตริงอย่างน้อย 1 รายการ และให้คุณจํากัดตัวแฮนเดิลforeignfetch
ให้ตอบกลับเฉพาะคําขอจากโดเมนที่เฉพาะเจาะจงได้ เช่น หากคุณอนุญาต "https://example.com" อย่างชัดแจ้ง คำขอที่ส่งจากหน้าที่โฮสต์ที่https://example.com/path/to/page.html
สำหรับทรัพยากรที่แสดงจากขอบเขตการดึงข้อมูลภายนอกจะทริกเกอร์ตัวแฮนเดิลการดึงข้อมูลภายนอก แต่คำขอที่ส่งจากhttps://random-domain.com/path/to/page.html
จะไม่ทริกเกอร์ตัวแฮนเดิล เว้นแต่คุณจะมีเหตุผลเฉพาะในการทริกเกอร์ตรรกะการดึงข้อมูลต่างประเทศสําหรับชุดย่อยของต้นทางระยะไกลเท่านั้น คุณก็ระบุ'*'
เป็นค่าเดียวในอาร์เรย์ได้ และระบบจะอนุญาตต้นทางทั้งหมด
เครื่องจัดการเหตุการณ์ foreignfetch
เมื่อติดตั้ง Service Worker ของบุคคลที่สามและกำหนดค่าผ่าน registerForeignFetch()
แล้ว Service Worker ดังกล่าวจะมีโอกาสสกัดกั้นคำขอทรัพยากรย่อยข้ามแหล่งที่มาไปยังเซิร์ฟเวอร์ของคุณซึ่งอยู่ภายในขอบเขตการดึงข้อมูลภายนอก
ใน Service Worker ของบุคคลที่หนึ่งที่เป็นแบบดั้งเดิม คําขอแต่ละรายการจะทริกเกอร์เหตุการณ์ fetch
ที่ Service Worker มีโอกาสตอบกลับ Service Worker ของบุคคลที่สามได้รับโอกาสให้จัดการเหตุการณ์ที่ต่างออกไปเล็กน้อยซึ่งมีชื่อว่า foreignfetch
ในแง่แนวคิด เหตุการณ์ทั้ง 2 รายการนี้ค่อนข้างคล้ายกัน และเปิดโอกาสให้คุณตรวจสอบคําขอขาเข้า รวมถึงตอบกลับคําขอผ่าน respondWith()
ได้ด้วยหากต้องการ
self.addEventListener('foreignfetch', event => {
// Assume that requestLogic() is a custom function that takes
// a Request and returns a Promise which resolves with a Response.
event.respondWith(
requestLogic(event.request).then(response => {
return {
response: response,
// Omit to origin to return an opaque response.
// With this set, the client will receive a CORS response.
origin: event.origin,
// Omit headers unless you need additional header filtering.
// With this set, only Content-Type will be exposed.
headers: ['Content-Type']
};
})
);
});
แม้ว่าแนวคิดจะคล้ายกัน แต่การใช้งานจริงจะแตกต่างกันเล็กน้อยเมื่อเรียกใช้ respondWith()
ใน ForeignFetchEvent
แทนที่จะระบุเพียง Response
(หรือ Promise
ที่จับคู่กับ Response
) ให้กับ respondWith()
เช่นเดียวกับที่ทำกับ FetchEvent
คุณต้องส่ง Promise
ที่จับคู่กับออบเจ็กต์ที่มีพร็อพเพอร์ตี้ที่เฉพาะเจาะจงไปยัง respondWith()
ของ ForeignFetchEvent
ดังนี้
response
ต้องระบุและต้องตั้งค่าเป็นออบเจ็กต์Response
ที่จะส่งกลับไปยังไคลเอ็นต์ที่ส่งคำขอ หากคุณระบุข้อมูลอื่นที่ไม่ใช่Response
ที่ถูกต้อง คำขอของลูกค้าจะสิ้นสุดลงด้วยข้อผิดพลาดเกี่ยวกับเครือข่าย ซึ่งแตกต่างจากการเรียกrespondWith()
ภายในตัวแฮนเดิลเหตุการณ์fetch
ตรงที่คุณต้องระบุResponse
ที่นี่ ไม่ใช่Promise
ซึ่งจะแสดงผลเป็นResponse
คุณสามารถสร้างคำตอบผ่านเชนพรอมต์ และส่งเชนนั้นผ่านพารามิเตอร์ไปยังrespondWith()
ของforeignfetch
ได้ แต่เชนต้องคลายกับออบเจ็กต์ที่มีการตั้งค่าพร็อพเพอร์ตี้response
เป็นออบเจ็กต์Response
คุณดูการสาธิตนี้ได้ในตัวอย่างโค้ดด้านบนorigin
ไม่บังคับ และใช้เพื่อระบุว่าคำตอบที่แสดงเป็นแบบทึบหรือไม่ หากไม่ระบุค่านี้ คำตอบจะเป็นแบบทึบ และไคลเอ็นต์จะมีสิทธิ์เข้าถึงเนื้อหาและส่วนหัวของคำตอบแบบจำกัด หากส่งคำขอด้วยmode: 'cors'
ระบบจะถือว่าการตอบกลับแบบทึบเป็นข้อผิดพลาด อย่างไรก็ตาม หากคุณระบุค่าสตริงเท่ากับต้นทางของไคลเอ็นต์ระยะไกล (ซึ่งรับได้ผ่านevent.origin
) แสดงว่าคุณเลือกที่จะให้การตอบกลับที่เปิดใช้ CORS แก่ไคลเอ็นต์อย่างชัดเจนheaders
ก็เป็นตัวเลือกเช่นกัน และจะใช้ได้ก็ต่อเมื่อคุณระบุorigin
และแสดงผลลัพธ์ CORS ด้วย โดยค่าเริ่มต้น ระบบจะรวมเฉพาะส่วนหัวในรายการส่วนหัวการตอบกลับที่อยู่ในรายการที่ปลอดภัยของ CORS ในการตอบกลับ หากต้องการกรองสิ่งที่แสดงผลเพิ่มเติม ส่วนหัวจะรับรายการชื่อส่วนหัวอย่างน้อย 1 รายการ และใช้รายการดังกล่าวเป็นรายการที่อนุญาตสำหรับส่วนหัวที่จะแสดงในการตอบกลับ ซึ่งจะช่วยให้คุณเลือกใช้ CORS ได้ในขณะที่ยังคงป้องกันไม่ให้ไคลเอ็นต์ระยะไกลเข้าถึงส่วนหัวการตอบกลับที่อาจมีความละเอียดอ่อนได้โดยตรง
โปรดทราบว่าเมื่อเรียกใช้ตัวแฮนเดิล foreignfetch
ตัวแฮนเดิลจะมีสิทธิ์เข้าถึงข้อมูลเข้าสู่ระบบทั้งหมดและสิทธิ์เข้าถึงแบบรอบข้างของต้นทางที่โฮสต์ Service Worker ในฐานะนักพัฒนาแอปที่ใช้งาน Service Worker ที่เปิดใช้การดึงข้อมูลจากต่างประเทศ คุณมีหน้าที่ตรวจสอบว่าไม่ได้เปิดเผยข้อมูลการตอบกลับที่มีสิทธิ์ซึ่งจะไม่สามารถเข้าถึงได้หากไม่มีข้อมูลเข้าสู่ระบบเหล่านั้น การกําหนดให้เลือกใช้การตอบกลับ CORS เป็นขั้นตอนหนึ่งในการจํากัดการเปิดเผยโดยไม่ตั้งใจ แต่ในฐานะนักพัฒนาแอป คุณสามารถส่งคําขอ fetch()
ภายในตัวแฮนเดิล foreignfetch
อย่างชัดเจนซึ่งไม่ใช้ข้อมูลเข้าสู่ระบบโดยนัยได้ผ่านการดำเนินการต่อไปนี้
self.addEventListener('foreignfetch', event => {
// The new Request will have credentials omitted by default.
const noCredentialsRequest = new Request(event.request.url);
event.respondWith(
// Replace with your own request logic as appropriate.
fetch(noCredentialsRequest)
.catch(() => caches.match(noCredentialsRequest))
.then(response => ({response}))
);
});
สิ่งที่ควรพิจารณาสำหรับลูกค้า
มีข้อควรพิจารณาเพิ่มเติมบางอย่างที่ส่งผลต่อวิธีที่ผู้ให้บริการการดึงข้อมูลต่างประเทศจัดการคําขอจากลูกค้าของบริการ
ลูกค้าที่มี Service Worker ของบุคคลที่หนึ่งของตนเอง
ลูกค้าบางรายของบริการของคุณอาจมี Service Worker ของบุคคลที่หนึ่งอยู่แล้ว ซึ่งจัดการคําขอที่มาจากเว็บแอปของตน สิ่งนี้จะส่งผลต่อ Service Worker ของบุคคลที่สามที่ดึงข้อมูลจากภายนอกอย่างไร
แฮนเดิล fetch
ใน Service Worker ของบุคคลที่หนึ่งจะได้รับโอกาสแรกในการตอบกลับคําขอทั้งหมดที่เว็บแอปส่งมา แม้ว่าจะมี Service Worker ของบุคคลที่สามที่เปิดใช้ foreignfetch
ด้วยขอบเขตที่ครอบคลุมคําขอก็ตาม แต่ลูกค้าที่มี Service Worker ของบุคคลที่หนึ่งจะยังคงใช้ประโยชน์จาก Service Worker สำหรับการดึงข้อมูลจากต่างประเทศได้
ใน Service Worker ของบุคคลที่หนึ่ง การใช้ fetch()
เพื่อดึงข้อมูลข้ามแหล่งที่มาจะทริกเกอร์ Service Worker สำหรับการดึงข้อมูลภายนอกที่เหมาะสม ซึ่งหมายความว่าโค้ดต่อไปนี้สามารถใช้ประโยชน์จากตัวแฮนเดิล foreignfetch
// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
// If event.request is under your foreign fetch service worker's
// scope, this will trigger your foreignfetch handler.
event.respondWith(fetch(event.request));
});
ในทํานองเดียวกัน หากมีตัวแฮนเดิลการดึงข้อมูลของบุคคลที่หนึ่ง แต่ไม่ได้เรียก event.respondWith()
เมื่อจัดการคําขอทรัพยากรข้ามแหล่งที่มา คําขอจะ "ส่งต่อ" ไปยังตัวแฮนเดิล foreignfetch
โดยอัตโนมัติ
// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
if (event.request.mode === 'same-origin') {
event.respondWith(localRequestLogic(event.request));
}
// Since event.respondWith() isn't called for cross-origin requests,
// any foreignfetch handlers scoped to the request will get a chance
// to provide a response.
});
หากตัวแฮนเดิล fetch
ของบุคคลที่หนึ่งเรียก event.respondWith()
แต่ไม่ได้ใช้ fetch()
เพื่อขอทรัพยากรภายใต้ขอบเขตการดึงข้อมูลภายนอก Service Worker สำหรับการดึงข้อมูลภายนอกจะไม่มีสิทธิ์จัดการคําขอ
ลูกค้าที่ไม่มี Service Worker ของตนเอง
ลูกค้าทุกรายที่ส่งคำขอไปยังบริการของบุคคลที่สามจะได้รับประโยชน์เมื่อบริการดังกล่าวติดตั้งใช้งาน Service Worker สำหรับการดึงข้อมูลจากภายนอก แม้ว่าลูกค้าจะไม่ได้ใช้บริการ Service Worker ของตนเองก็ตาม ไคลเอ็นต์ไม่จำเป็นต้องดำเนินการใดๆ เป็นพิเศษเพื่อเลือกใช้บริการเรียกข้อมูลของบุคคลที่สาม ตราบใดที่ใช้เบราว์เซอร์ที่รองรับ ซึ่งหมายความว่าเมื่อใช้เวิร์กเกอร์บริการการดึงข้อมูลภายนอก ตรรกะคำขอที่กำหนดเองและแคชที่แชร์จะเป็นประโยชน์ต่อไคลเอ็นต์จำนวนมากของบริการทันทีโดยไม่ต้องดำเนินการใดๆ เพิ่มเติม
สรุปข้อมูลทั้งหมด: ตำแหน่งที่ลูกค้ามองหาคําตอบ
เมื่อพิจารณาข้อมูลข้างต้นแล้ว เราจะจัดลำดับลําดับชั้นของแหล่งที่มาที่ไคลเอ็นต์จะใช้เพื่อค้นหาคําตอบสําหรับคําขอข้ามแหล่งที่มาได้
- แฮนเดิล
fetch
ของ Service Worker ของบุคคลที่หนึ่ง (หากมี) - แฮนเดิล
foreignfetch
ของ Service Worker ของบุคคลที่สาม (หากมี และสำหรับคำขอข้ามแหล่งที่มาเท่านั้น) - แคช HTTP ของเบราว์เซอร์ (หากมีการตอบกลับใหม่)
- เครือข่าย
เบราว์เซอร์จะเริ่มต้นจากด้านบนและจะดูรายการต่อๆ ไปจนกว่าจะพบแหล่งที่มาของการตอบกลับ ทั้งนี้ขึ้นอยู่กับการใช้งาน Service Worker
ดูข้อมูลเพิ่มเติม
- คำอธิบายการดึงข้อมูลจากต่างประเทศ
- โค้ดตัวอย่างและเดโมแบบเรียลไทม์
- เครื่องมือติดตามปัญหาเกี่ยวกับ Service Worker
ไม่พลาดรับข้อมูลอัปเดต
การใช้งานช่วงทดลองใช้จากต้นทางของ Chrome สำหรับการดึงข้อมูลจากต่างประเทศอาจมีการเปลี่ยนแปลงเมื่อเราจัดการกับความคิดเห็นที่ได้รับจากนักพัฒนาซอฟต์แวร์ เราจะอัปเดตโพสต์นี้อยู่เสมอผ่านการเปลี่ยนแปลงในบทสนทนา และจะบันทึกการเปลี่ยนแปลงที่เฉพาะเจาะจงไว้ด้านล่างเมื่อเกิดการเปลี่ยนแปลง นอกจากนี้ เราจะแชร์ข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่สำคัญผ่านบัญชี Twitter ของ @chromiumdev ด้วย