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

เจฟฟ์ พอสนิก
เจฟฟ์ พอสนิก

ที่มา

Service Worker ช่วยให้นักพัฒนาเว็บตอบสนองคำขอเครือข่ายที่สร้างโดยเว็บแอปพลิเคชัน ทำให้ทำงานต่อได้แม้ในขณะออฟไลน์, Fight Lie-Fi, และใช้การโต้ตอบในแคชที่ซับซ้อน เช่น ไม่อัปเดตขณะตรวจสอบใหม่ แต่ก่อนหน้านี้ Service Worker มีการผูกมัดกับต้นทางหนึ่งๆ โดยตรง ในฐานะเจ้าของเว็บแอป คุณมีหน้าที่เขียนและทำให้ Service Worker ใช้งานได้เพื่อสกัดกั้นคำขอเครือข่ายทั้งหมดที่เว็บแอปสร้างขึ้น ในรูปแบบดังกล่าว โปรแกรมทำงานของบริการแต่ละรายจะมีหน้าที่จัดการคำขอแบบข้ามต้นทาง เช่น คำขอที่ส่งไปยัง API ของบุคคลที่สามหรือสำหรับแบบอักษรสำหรับเว็บ

จะเกิดอะไรขึ้นหากผู้ให้บริการบุคคลที่สามของ API หรือแบบอักษรบนเว็บ หรือบริการที่ใช้กันโดยทั่วไปอื่นๆ มีอำนาจในการทำให้ Service Worker ของตนใช้งานได้ซึ่งมีโอกาสจัดการคำขอจากต้นทางอื่นซึ่งมาจากต้นทางนั้นๆ ผู้ให้บริการสามารถใช้ตรรกะเครือข่ายที่กำหนดเอง และใช้ประโยชน์จากอินสแตนซ์ของแคชที่เชื่อถือได้รายการเดียวในการจัดเก็บคำตอบ ตอนนี้ ต้องขอบคุณการดึงข้อมูลจากต่างประเทศ ซึ่งทำให้การติดตั้งใช้งาน Service Worker ของบุคคลที่สามประเภทดังกล่าวเป็นจริงแล้ว

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

  • ผู้ให้บริการ API ที่มีอินเทอร์เฟซ RESTful
  • ผู้ให้บริการเว็บฟอนต์
  • ผู้ให้บริการ Analytics
  • ผู้ให้บริการโฮสติ้งภาพ
  • เครือข่ายนำส่งข้อมูลทั่วไป

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

ข้อกำหนดเบื้องต้น

โทเค็นช่วงทดลองใช้จากต้นทาง

การดึงข้อมูลจากต่างประเทศยังถือว่าเป็นการทดลอง เพื่อไม่ให้ Bake การออกแบบนี้ก่อนเวลา ก่อนที่จะระบุอย่างสมบูรณ์และตกลงจากผู้ให้บริการเบราว์เซอร์ จึงมีการติดตั้งใช้งานใน Chrome 54 เป็นช่วงทดลองใช้จากต้นทาง ตราบใดที่การดึงข้อมูลภายนอกยังคงอยู่ระหว่างการทดสอบ หากต้องการใช้ฟีเจอร์ใหม่นี้กับบริการที่คุณโฮสต์ คุณจะต้องขอโทเค็นที่กำหนดขอบเขตอยู่ที่ต้นทางของบริการนั้นโดยเฉพาะ โทเค็นนี้ควรรวมอยู่ในส่วนหัวการตอบกลับ HTTP ในคำขอแบบข้ามต้นทางทั้งหมดสำหรับทรัพยากรที่คุณต้องการจัดการผ่านการดึงข้อมูลจากต่างประเทศ รวมถึงในการตอบสนองสำหรับทรัพยากร JavaScript ของโปรแกรมทำงานด้วย

Origin-Trial: token_obtained_from_signup

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

เพื่ออำนวยความสะดวกในการทดสอบการดึงข้อมูลต่างประเทศก่อนลงทะเบียนโทเค็นช่วงทดลองใช้จากต้นทางอย่างเป็นทางการ คุณข้ามข้อกำหนดใน Chrome สำหรับคอมพิวเตอร์ในระบบได้โดยไปที่ chrome://flags/#enable-experimental-web-platform-features และเปิดใช้แฟล็ก "ฟีเจอร์แพลตฟอร์มเว็บรุ่นทดลอง" โปรดทราบว่าคุณต้องทำขั้นตอนนี้ใน Chrome ทุกอินสแตนซ์ที่ต้องการใช้ในการทดสอบในเครื่อง ในขณะที่ผู้ใช้ Chrome ทุกคนใช้ฟีเจอร์นี้ได้เมื่อใช้โทเค็นช่วงทดลองใช้จากต้นทาง

HTTPS

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

การใช้การดึงข้อมูลจากต่างประเทศ

เนื่องจากมีข้อกำหนดเบื้องต้นมาอย่างคร่าวๆ แล้ว เรามาเจาะลึกรายละเอียดทางเทคนิคที่จำเป็นต่อการทำให้โปรแกรมการดึงข้อมูลจากต่างประเทศพร้อมใช้งานกันดีกว่า

กำลังลงทะเบียน Service Worker

ความท้าทายแรกที่คุณน่าจะพบเจอคือวิธีลงทะเบียน Service Worker หากคุณเคยทำงานร่วมกับโปรแกรมทำงานของบริการมาก่อน คุณอาจคุ้นเคยกับสิ่งต่อไปนี้

// You can't do this!
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('service-worker.js');
}

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

โซลูชันนี้จะมาในรูปแบบส่วนหัว HTTP ที่เซิร์ฟเวอร์ใส่ไว้ในการตอบกลับใดก็ได้

Link: </service-worker.js>; rel="serviceworker"; scope="/"

มาดูรายละเอียดส่วนหัวตัวอย่างเป็นคอมโพเนนต์ โดยแต่ละส่วนหัวคั่นด้วยอักขระ ;

  • ต้องระบุ </service-worker.js> และใช้เพื่อระบุเส้นทางไปยังไฟล์โปรแกรมทำงานของบริการ (แทนที่ /service-worker.js ด้วยเส้นทางที่เหมาะสมไปยังสคริปต์) ซึ่งสอดคล้องโดยตรงกับสตริง scriptURL มิเช่นนั้นจะส่งไปเป็นพารามิเตอร์แรกไปยัง navigator.serviceWorker.register() ค่าต้องอยู่ใน <> อักขระ (ตามที่ข้อกําหนดของส่วนหัว Link กําหนด) และหากมีการระบุ 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

การแก้ไขข้อบกพร่องของการลงทะเบียน

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

มีการส่งส่วนหัวการตอบกลับที่ถูกต้องไหม

หากต้องการลงทะเบียนโปรแกรมทำงานของบริการการดึงข้อมูลต่างประเทศ คุณต้องตั้งค่าส่วนหัวของลิงก์ในคำตอบสำหรับทรัพยากรที่โฮสต์ในโดเมนของคุณตามที่อธิบายไว้ก่อนหน้านี้ในโพสต์นี้ ในระหว่างช่วงทดลองใช้จากต้นทาง และในกรณีที่ไม่ได้ตั้งค่า chrome://flags/#enable-experimental-web-platform-features ไว้ คุณจะต้องตั้งค่าส่วนหัวการตอบกลับ Origin-Trial ด้วย คุณยืนยันว่าเว็บเซิร์ฟเวอร์กำลังตั้งค่าส่วนหัวได้โดยดูที่รายการในแผงเครือข่ายของเครื่องมือสำหรับนักพัฒนาเว็บ ดังนี้

ส่วนหัวที่แสดงในแผงเครือข่าย

Foreign Fetch Service Worker ได้รับการลงทะเบียนอย่างถูกต้องหรือไม่

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

โปรแกรมทำงานของบริการดึงข้อมูลจากต่างประเทศในแผงแอปพลิเคชัน

เครื่องจัดการเหตุการณ์การติดตั้ง

เมื่อคุณได้ลงทะเบียน Service Worker ของบุคคลที่สามแล้ว ก็จะมีโอกาสตอบกลับเหตุการณ์ install และ activate เหมือนที่ Service Worker อื่นๆ จะทำได้ โดยอาจใช้ประโยชน์จากเหตุการณ์เหล่านั้น เช่น เติมแคชด้วยทรัพยากรที่จำเป็นในระหว่างเหตุการณ์ install หรือตัดแคชที่ล้าสมัยในเหตุการณ์ activate

นอกเหนือจากกิจกรรมการแคชเหตุการณ์ install ปกติแล้ว ยังมีขั้นตอนเพิ่มเติมที่จำเป็นในเครื่องจัดการเหตุการณ์ install ของ 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 อเนกประสงค์ใช้งานได้ซึ่งสามารถจัดการทั้งเหตุการณ์ fetch ของบุคคลที่หนึ่ง (สำหรับคำขอจากเว็บไซต์ของคุณเอง) และเหตุการณ์ foreignfetch ของบุคคลที่สาม (สำหรับคำขอจากโดเมนอื่น) และระบุอย่างชัดเจนว่าควรเรียกใช้ foreignfetch ในขอบเขตที่ใหญ่กว่าเท่านั้น ในทางปฏิบัติ หากคุณกำลังทำให้ Service Worker ทำงานเพื่อให้จัดการเฉพาะเหตุการณ์ foreignfetch ของบุคคลที่สามโดยเฉพาะ คุณจะต้องใช้ขอบเขตที่ชัดเจนเพียงขอบเขตเดียวที่เท่ากับขอบเขตโดยรวมของโปรแกรมทำงานของบริการ ตัวอย่างด้านบนจะทําตามข้างต้น โดยใช้ค่า self.registration.scope
  • origins ใช้อาร์เรย์ของสตริงอย่างน้อย 1 สตริงและให้คุณจำกัดตัวแฮนเดิล foreignfetch ให้ตอบสนองต่อคำขอจากโดเมนที่ระบุเท่านั้น ตัวอย่างเช่น หากคุณอนุญาต "https://example.com" อย่างชัดแจ้ง คำขอที่สร้างจากหน้าเว็บที่โฮสต์ที่ https://example.com/path/to/page.html สำหรับทรัพยากรที่ให้บริการจากขอบเขตการดึงข้อมูลต่างประเทศจะเรียกตัวแฮนเดิลการดึงข้อมูลต่างประเทศ แต่คำขอที่สร้างจาก https://random-domain.com/path/to/page.html จะไม่ทริกเกอร์เครื่องจัดการ คุณจะระบุ '*' เป็นค่าเดียวในอาร์เรย์ได้ เว้นแต่ว่าคุณจะมีเหตุผลเฉพาะในการทริกเกอร์ตรรกะการดึงข้อมูลต่างประเทศสำหรับต้นทางระยะไกลบางส่วน

เครื่องจัดการเหตุการณ์ต่างประเทศ

ตอนนี้เมื่อคุณได้ติดตั้ง Service Worker ของบุคคลที่สามและกำหนดค่าแล้วผ่าน registerForeignFetch() แล้ว โปรแกรมนี้จะมีโอกาสสกัดกั้นคำขอทรัพยากรย่อยแบบข้ามต้นทางไปยังเซิร์ฟเวอร์ที่อยู่ในขอบเขตการดึงข้อมูลภายนอก

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

เครื่องจัดการ fetch ใน Service Worker ของบุคคลที่หนึ่งจะได้รับโอกาสแรกในการตอบสนองคำขอทั้งหมดที่ส่งมาจากเว็บแอป แม้ว่าจะมี Service Worker ของบุคคลที่สามที่เปิดใช้ foreignfetch โดยมีขอบเขตที่ครอบคลุมคำขอก็ตาม แต่ลูกค้าที่มี Service Worker ของบุคคลที่หนึ่งยังใช้ประโยชน์จาก Service Worker จากต่างประเทศได้

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

นำทุกอย่างมารวมกัน: ในที่ที่ลูกค้าต้องการคำตอบ

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

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

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

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

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

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