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

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

Hiroki Kumazaki

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

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

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

הורדת קובצי 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 לא יהיה תקף.

כדי לפתור את הבעיה, קיימת עכשיו תכונה ניסיונית של שליפה מראש (prefetch) של משאבי משנה של 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=". כאן מציינים את משאב המשנה שאפשר להחליף בגיבוב (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]. אפשר גם להצטרף לדיון על המפרט או לדווח על באג לצוות. המשוב שלכם יעזור מאוד בתהליך הסטנדרטיזציה וגם יעזור לטפל בבעיות הטמעה. תודה!