ผู้ปฏิบัติงานบริการข้ามต้นทาง - การทดสอบการดึงข้อมูลจากต่างประเทศ

ข้อมูลเบื้องต้น

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 ของบุคคลที่สามแล้ว 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 ของตนเองก็ตาม ไคลเอ็นต์ไม่จำเป็นต้องดำเนินการใดๆ เป็นพิเศษเพื่อเลือกใช้บริการเรียกข้อมูลของบุคคลที่สาม ตราบใดที่ใช้เบราว์เซอร์ที่รองรับ ซึ่งหมายความว่าเมื่อใช้เวิร์กเกอร์บริการการดึงข้อมูลภายนอก ตรรกะคำขอที่กำหนดเองและแคชที่แชร์จะเป็นประโยชน์ต่อไคลเอ็นต์จำนวนมากของบริการทันทีโดยไม่ต้องดำเนินการใดๆ เพิ่มเติม

สรุปข้อมูลทั้งหมด: ตำแหน่งที่ลูกค้ามองหาคําตอบ

เมื่อพิจารณาข้อมูลข้างต้นแล้ว เราจะจัดลำดับลําดับชั้นของแหล่งที่มาที่ไคลเอ็นต์จะใช้เพื่อค้นหาคําตอบสําหรับคําขอข้ามแหล่งที่มาได้

  1. แฮนเดิล fetch ของ Service Worker ของบุคคลที่หนึ่ง (หากมี)
  2. แฮนเดิล foreignfetch ของ Service Worker ของบุคคลที่สาม (หากมี และสำหรับคำขอข้ามแหล่งที่มาเท่านั้น)
  3. แคช HTTP ของเบราว์เซอร์ (หากมีการตอบกลับใหม่)
  4. เครือข่าย

เบราว์เซอร์จะเริ่มต้นจากด้านบนและจะดูรายการต่อๆ ไปจนกว่าจะพบแหล่งที่มาของการตอบกลับ ทั้งนี้ขึ้นอยู่กับการใช้งาน Service Worker

ดูข้อมูลเพิ่มเติม

ไม่พลาดรับข้อมูลอัปเดต

การใช้งานช่วงทดลองใช้จากต้นทางของ Chrome สำหรับการดึงข้อมูลจากต่างประเทศอาจมีการเปลี่ยนแปลงเมื่อเราจัดการกับความคิดเห็นที่ได้รับจากนักพัฒนาซอฟต์แวร์ เราจะอัปเดตโพสต์นี้อยู่เสมอผ่านการเปลี่ยนแปลงในบทสนทนา และจะบันทึกการเปลี่ยนแปลงที่เฉพาะเจาะจงไว้ด้านล่างเมื่อเกิดการเปลี่ยนแปลง นอกจากนี้ เราจะแชร์ข้อมูลเกี่ยวกับการเปลี่ยนแปลงที่สำคัญผ่านบัญชี Twitter ของ @chromiumdev ด้วย