איך להפיץ Signed HTTP Exchange (SXG) באמצעות nginx

איך מקבלים ומגישים קובצי SXG באמצעות nginx, והאתגרים של אחסון מראש של משאבי משנה.

Hiroki Kumazaki

בתור מפיץ של Signed HTTP Exchanges‏ (SXG), אתם יכולים לספק קובצי SXG בשם יוצרי התוכן המקורי. דפדפני אינטרנט שתומכים ב-SXG יציג קבצי SXG כאלה כאילו הם נשלחו מיוצרי התוכן המקוריים. כך תוכלו להטמיע טעינה מראש בכמה אתרים בלי לפגוע בפרטיות. במדריך הזה נסביר איך להפיץ קובצי SXG בצורה נכונה.

תמיכה בדפדפנים שונים

Chrome הוא הדפדפן היחיד שתומך כרגע ב-SXG. מידע עדכני יותר זמין בקטע 'הסכמה וסטנדרטיזציה' במאמר החלפות HTTP בחתימה של המקור.

אחזור של קובצי 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.sxg מהשירות שלו ומנסה לשנות את https://website.test/app.js לגרסה של המפיץ של המשאב המשני הזה (למשל https://distributor.test/website.test/app.js.sxg), הוא יגרום לחוסר התאמה בחתימה ויגרום ל-SXG להיות לא תקף.

כדי לפתור את הבעיה, יש עכשיו ב-Chrome תכונה ניסיונית של אחסון מראש של משאבי משנה מסוג SXG. אפשר להפעיל אותו בכתובת: 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=". זהו המשאב המשני שאפשר להחליף ב-hash הספציפי של תקינות ה-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 ומתאים למשאב המשנה.

האפשרות הראשונה היא קלה יחסית, כי nginx-sxg-module יכול לחשב גיבוב תקינות ולהטמיע אותו בכותרות קישורים מתשובות מ-upstream. אבל האפשרות השנייה קשה יותר, כי מפיצת התוכן צריכה לדעת על המשאבים המשניים שצוינו ב-SXG.

אם אין משאבי משנה מלבד https://website.test/app.js, כל מה שצריך להוסיף לקובץ התצורה של nginx הוא:

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

אבל מקרים כאלה נדירים, כי אתרים רגילים מורכבים מלא מעט משאבי משנה. בנוסף, המפיץ צריך לצרף את הכותרת המתאימה של קישור העוגן כשמציגים קובץ SXG. נכון לעכשיו אין דרך קלה לפתור את הבעיה הזו, אז כדאי לעקוב אחרי עדכונים.

שליחת משוב

מהנדסי Chromium ישמחו לקבל מכם משוב על הפצת SXG בכתובת [e-mail]. אפשר גם להצטרף לדיון על המפרט או לדווח לצוות על באג. המשוב שלכם יעזור מאוד בתהליך התקינה, וגם יעזור לטפל בבעיות בהטמעה. תודה!