Signed HTTP Exchange (או SXG) הוא קבוצת משנה של הטכנולוגיה המתפתחת שנקראת Web Packages, שמאפשרת לבעלי תוכן דיגיטלי להפוך את התוכן שלהם לנייד, כלומר זמין להפצה מחדש על ידי גורמים אחרים, תוך שמירה על שלמות התוכן ועל השיוך שלו. לתוכן נייד יש יתרונות רבים, החל מהעברת תוכן מהר יותר ועד לאפשרות לשתף תוכן בין משתמשים וליהנות מחוויית שימוש פשוטה יותר במצב אופליין.
אז איך פועלים Signed HTTP Exchanges? הטכנולוגיה הזו מאפשרת לבעלי תוכן דיגיטלי לחתום על החלפת HTTP אחת (כלומר זוג בקשה/תשובה), כך שאפשר להציג את החלפת ה-HTTP החתומה מכל שרת מטמון. כשהדפדפן טוען את ה-Signed Exchange הזה, הוא יכול להציג בבטחה את כתובת ה-URL של בעל התוכן בסרגל הכתובות, כי החתימה ב-exchange מספיקה כדי להוכיח שהתוכן הגיע במקור מהמקור של בעל התוכן.
כך אפשר לנתק את המקור של התוכן ממי שמפיץ אותו. תוכלו לפרסם את התוכן שלכם באינטרנט בלי להסתמך על שרת, חיבור או שירות אירוח ספציפיים. אנחנו מתרגשים מהשימושים האפשריים ב-SXG, כמו:
אחסון מראש לשמירה על הפרטיות: אמנם אחסון מראש של משאבים (למשל, על ידי קישור rel=prefetch) לצורך ניווט עתידי יכול להאיץ את הניווט, אבל יש לכך גם חסרונות מבחינת הפרטיות. לדוגמה, אחסון מראש של משאבים לניווט בין מקורות יעיד בפני אתר היעד שהמשתמש עשוי להתעניין בחלק מהמידע, גם אם הוא לא ביקר באתר בסופו של דבר. לעומת זאת, SXG מאפשר טעינה מראש של משאבים ממקורות שונים מתוך מטמון מהיר, בלי להגיע לאתר היעד, וכך להעביר את העניין של המשתמש רק אם והפעם שבה מתרחשת הניווט. לדעתנו, האפשרות הזו יכולה להיות שימושית לאתרים שהמטרה שלהם היא לשלוח את המשתמשים לאתרים אחרים. במיוחד, Google מתכננת להשתמש בכך בדפי תוצאות החיפוש ב-Google כדי לשפר את כתובות ה-URL של AMP ולהאיץ את קצב הקליקים על תוצאות החיפוש.
היתרונות של CDN בלי לוותר על השליטה במפתח הפרטי של האישור: תוכן שהפך לפופולרי באופן פתאומי (למשל, קישור מהדף הראשון של reddit.com) לעיתים קרובות יוצר עומס יתר באתר שבו התוכן מוצג. אם האתר קטן יחסית, הוא עשוי להאט או להיות לא זמין באופן זמני. אפשר למנוע את המצב הזה אם התוכן משותף באמצעות שרתי מטמון מהירים וחזקים, ו-SXG מאפשר לעשות זאת בלי לשתף את מפתחות ה-TLS.
ניסיון בהחלפות חתומות
Signed Exchanges זמינים ב-Chrome מגרסה 73 ואילך, והיו זמינים בעבר כגרסת מקור לניסיון.
יצירת קובץ SXG
כדי ליצור קובצי SXG למקור (כמוביל תוכן דיגיטלי), צריך מפתח אישור כדי לחתום על החתימה, והאישור צריך לכלול את התוסף המיוחד 'CanSignHttpExchanges' כדי שיעובד כקובץ SXG תקין. נכון לנובמבר 2018, DigiCert היא ה-CA היחיד שתומך בתוסף הזה, וניתן לבקש את האישור שפועל ב-SXG בדף הזה.
אחרי שתקבלו אישור SXG, תוכלו ליצור קובצי SXG משלכם באמצעות כלים ליצירת קובצי עזר שפורסמו ב-GitHub.
אפשר גם לעיין בקובצי הדוגמה בפועל של SXG במאגר הקוד של Chrome (לדוגמה, הקובץ הזה הוא הפשוט ביותר שנוצר עבור קובץ טקסט פשוט). חשוב לזכור שהם נוצרים בעיקר לצורך בדיקה מקומית, ולכן לא צפויים להיות להם אישורים ותגי זמן תקפים בחתימה.
בדיקת התכונה באופן מקומי
כדי ליצור קובצי SXG למטרות בדיקה, אפשר ליצור אישור בחתימה עצמית ולהפעיל את chrome://flags/#allow-sxg-certs-without-extension כדי ש-Chrome יעבד את קובצי ה-SXG שנוצרו באמצעות האישור בלי התוסף המיוחד.
קוד כמו זה אמור לפעול אם השרת, האישור וה-SXGs מוגדרים בצורה נכונה:
<!-- prefetch the sample.sxg -->
<link rel="prefetch" href="https://your-site.com/sample.sxg" />
<!-- clicking the link below should make Chrome navigate to the inner
response of sample.sxg (and the prefetched SXG is used) -->
<a href="https://your-site.com/sample.sxg">Sample</a>
לתשומת ליבכם: ה-SXG נתמך רק בתג העוגן (<a>) וב-link rel=prefetch ב-Chrome מגרסה 73 ואילך. חשוב גם לדעת שהתוקף של החתימה מוגבל ל-7 ימים לכל מפרט, כך שתוקף התוכן החתום יפוג מהר יחסית.
שליחת משוב
נשמח לקבל מכם משוב על הניסוי הזה בכתובת webpackage-dev@chromium.org. אפשר גם להצטרף לדיון בנושא המפרט או לדווח לצוות על באג ב-Chrome. המשוב שלכם יעזור לנו מאוד בתהליך התקינה, וגם יעזור לנו לטפל בבעיות בהטמעה.