วิธีแจกจ่าย Signed HTTP Exchange (SXG) โดยใช้ nginx

วิธีรับและแสดงไฟล์ SXG โดยใช้ nginx และความท้าทายของการดึงข้อมูลทรัพยากรย่อยล่วงหน้า

ฮิโรกิ คุมาซากิ
ฮิโรกิ คุมาซากิ

ในฐานะผู้จัดจำหน่าย Signed HTTP Exchange (SXG) คุณสามารถส่งไฟล์ SXG ในนามของครีเอเตอร์เนื้อหาต้นฉบับได้ เว็บเบราว์เซอร์ที่รองรับ SXG จะแสดงไฟล์ SXG ดังกล่าวราวกับว่าส่งมาจากผู้สร้างเนื้อหาต้นฉบับ ซึ่งจะช่วยให้คุณใช้งานการโหลดล่วงหน้าข้ามเว็บไซต์ได้โดยไม่ละเมิดความเป็นส่วนตัว คู่มือนี้แสดงวิธีเผยแพร่ SXG อย่างถูกต้อง

การสนับสนุนในเบราว์เซอร์ต่างๆ

ปัจจุบัน Chrome เป็นเบราว์เซอร์เดียวที่รองรับ SXG โปรดดูข้อมูลล่าสุดในส่วน "ฉันทามติและมาตรฐาน" ของ Origin-Signed HTTP Exchange

รับไฟล์ SXG

ระบุในส่วนหัวของคำขอ Accept ที่ต้องการให้เซิร์ฟเวอร์ส่งคืนไฟล์ SXG มาพร้อมกับคำขอดังนี้

Accept: application/signed-exchange;v=b3,*/*;q=0.8

คู่มือนี้จะถือว่าคุณวางไฟล์ SXG ไว้ใน /var/www/sxg

แสดงไฟล์ SXG แบบง่าย

แนบส่วนหัวต่อไปนี้เพื่อแจกจ่ายไฟล์ SXG ไฟล์เดียว

Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff

กำหนดค่า nginx:

http {
    ...
    types {
        application/signed-exchange;v=b3  sxg;
    }
    add_header X-Content-Type-Options nosniff;

    location / {
        more_set_headers "Content-Type: application/signed-exchange;v=b3";
        alias /var/www/sxg/;
        try_files $uri.sxg $uri =404;
        autoindex off;
    }
    ...

โหลดการกำหนดค่าใหม่ลงใน nginx:

sudo systemctl restart nginx.service

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

ดึงทรัพยากรย่อยล่วงหน้า

หน้าเว็บส่วนใหญ่ประกอบด้วยทรัพยากรย่อยหลายรายการ เช่น CSS, JavaScript, แบบอักษร และรูปภาพ คุณไม่สามารถเปลี่ยนแปลงเนื้อหาของ SXG ได้หากไม่มีคีย์ส่วนตัวของผู้สร้างเนื้อหา การดำเนินการนี้จะทำให้เกิดปัญหาเมื่อเบราว์เซอร์พยายามแก้ไขทรัพยากรย่อย

ตัวอย่างเช่น สมมติว่า index.html.sxg จาก https://website.test/index.html มีลิงก์ไปยัง https://website.test/app.js เมื่อเบราว์เซอร์ของผู้ใช้ได้รับไฟล์ SXG จาก https://distributor.test/example.com/index.html.sxg เบราว์เซอร์ของผู้ใช้จะเห็นลิงก์ไปยัง https://website.test/app.js เบราว์เซอร์สามารถดึงข้อมูล https://website.test/app.js จากการเข้าถึงจริงได้โดยตรง แต่ไม่ควรทำในขั้นตอนการโหลดล่วงหน้าเพื่อรักษาความเป็นส่วนตัว หากมีการดึงข้อมูลทรัพยากรในขั้นตอนการโหลดล่วงหน้า ครีเอเตอร์เนื้อหา (website.test) จะตรวจพบได้ว่าผู้เผยแพร่เนื้อหารายใด (distributor.test) กำลังขอทรัพยากร

ลิงก์ไปยัง app.js ใน distributor.test/index.html.sxg จะชี้ไปที่ website.test/app.js

หากผู้จัดจำหน่ายต้องการให้บริการ app.js.sxg จากบริการของตนเองและพยายามแก้ไข https://website.test/app.js ให้เป็นเวอร์ชันทรัพยากรย่อยดังกล่าวในเวอร์ชันของตัวแทนจำหน่าย (เช่น https://distributor.test/website.test/app.js.sxg) จะทำให้ลายเซ็นไม่ตรงกันและทำให้ SXG ไม่ถูกต้อง

การพยายามลิงก์การอ้างอิงกับ app.js ใน distributor.test/index.html.sxg ไปยัง distributor.test/app.js ทำให้ลายเซ็นไม่ตรงกัน

เพื่อแก้ไขปัญหานี้ ปัจจุบันมีฟีเจอร์การดึงข้อมูลทรัพยากรย่อย SXG ล่วงหน้าแบบทดลองใน Chrome คุณสามารถเปิดใช้ได้ที่: about://flags/#enable-sxg-subresource-prefetching หากต้องการใช้การดึงข้อมูลทรัพยากรย่อยล่วงหน้าต้องเป็นไปตามเงื่อนไขต่อไปนี้

  • ผู้เผยแพร่โฆษณาต้องฝังรายการส่วนหัวการตอบกลับใน SXG เช่น link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=" ซึ่งจะระบุทรัพยากรย่อยที่แทนที่ด้วยแฮชความสมบูรณ์เฉพาะของ SXG ได้
  • ผู้จัดจำหน่ายต้องแนบส่วนหัวการตอบกลับเมื่อให้บริการ SXG เช่น link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js" ข้อมูลนี้ระบุเส้นทางของ app.js และสอดคล้องกับทรัพยากรย่อย

แท็ก Anchor

วิธีแรกนั้นค่อนข้างง่ายเนื่องจาก nginx-sxg-module สามารถคำนวณแฮชความสมบูรณ์และฝังลงในส่วนหัวของลิงก์จากการตอบกลับอัปสตรีมได้ แต่เรื่องที่ 2 ยากกว่าเพราะผู้เผยแพร่เนื้อหาต้องทราบถึงทรัพยากรย่อยที่ระบุใน SXG

หากไม่มีทรัพยากรย่อยอื่นนอกเหนือจาก https://website.test/app.js สิ่งที่คุณต้องทำต่อท้ายในการกำหนดค่า nginx มีดังนี้

add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...

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

ส่งความคิดเห็น

วิศวกร Chromium ต้องการรับฟังความคิดเห็นของคุณเกี่ยวกับการเผยแพร่ SXG ที่ webpackage-dev@chromium.org นอกจากนี้ยังเข้าร่วมการพูดคุยเรื่องข้อกำหนดหรือรายงานข้อบกพร่องไปยังทีมได้ด้วย ความคิดเห็นของคุณจะช่วยในกระบวนการกำหนดมาตรฐานได้เป็นอย่างมาก และช่วยแก้ปัญหาการใช้งานด้วย ขอขอบคุณ