หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

Hiroki Kumazaki

ในฐานะผู้จัดจำหน่าย 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 นอกจากนี้ คุณยังเข้าร่วมการสนทนาเกี่ยวกับข้อกำหนดหรือรายงานข้อบกพร่องให้ทีมทราบได้ด้วย ความคิดเห็นของคุณจะช่วยในขั้นตอนการกำหนดมาตรฐานได้อย่างมากและช่วยแก้ปัญหาการใช้งาน ขอขอบคุณ