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