איך לקבל ולהציג קובצי SXG באמצעות nginx, והאתגרים של שליפה מראש של משאבי משנה.
מפיצים של 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 בכתובת webpackage-dev@chromium.org. אפשר גם להצטרף לדיון על המפרט או לדווח על באג לצוות. המשוב שלכם יעזור מאוד בתהליך הסטנדרטיזציה וגם יעזור לטפל בבעיות הטמעה. תודה!