Podpisana wymiana HTTP (lub „SXG”) to podzbiór nowej technologii nazywanej pakietami internetowymi, który umożliwia wydawcom bezpieczne przenoszenie treści (czyli udostępnienie ich do ponownej dystrybucji przez inne osoby z zachowaniem integralności i informacji o pochodzeniu danych). Przenośne treści mają wiele zalet: umożliwiają szybsze dostarczanie treści, udostępnianie treści między użytkownikami i łatwiejsze korzystanie z trybu offline.
Jak działają podpisane wymiany HTTP? Ta technologia umożliwia wydawcy podpisywanie pojedynczej wymiany HTTP (tj. pary żądania/odpowiedzi) w sposób, który może obsługiwać z dowolnego serwera pamięci podręcznej. Po wczytaniu Signed Exchange przeglądarka może bezpiecznie pokazać URL wydawcy na pasku adresu, ponieważ podpis w wymianie jest wystarczającym dowodem, że treść pochodzi z źródła wydawcy.
Pozwala to oddzielić pochodzenie treści od jej dystrybucji. Twoje treści mogą zostać opublikowane w internecie bez konieczności korzystania z konkretnego serwera, połączenia czy usługi hostingowej. Cieszymy się na temat możliwych zastosowań SXG, takich jak:
Wstępne pobieranie zasobów z zachowaniem prywatności: chociaż pobieranie zasobów z wyprzedzeniem (np. za pomocą linku rel=prefetch) na potrzeby późniejszej nawigacji może sprawić, że nawigacja będzie działać szybciej, lecz wiąże się to z wadami dotyczącymi ochrony prywatności. Na przykład pobieranie z wyprzedzeniem zasobów na potrzeby nawigacji w różnych domenach informuje witrynę docelową, że użytkownik może być zainteresowany daną informacją, nawet jeśli w ogóle jej nie odwiedził. Z drugiej strony SXG umożliwia wstępne pobieranie zasobów z innych domen z szybkiej pamięci podręcznej bez łączenia się z witryną docelową. Dzięki temu informuje o zainteresowaniu użytkownika tylko wtedy, gdy następuje nawigacja. Uważamy, że może to być przydatne dla witryn, których celem jest skierowanie użytkowników do innych witryn. Google zamierza korzystać z tej funkcji na stronach wyników wyszukiwania Google, aby ulepszyć adresy URL AMP i przyspieszyć kliknięcia w wynikach wyszukiwania.
Zalety korzystania z sieci CDN bez wymuszania kontroli nad kluczem prywatnym certyfikatu: treści, które nagle stały się popularne (np.linki z pierwszej strony reddit.com), często przeciążają witrynę, na której są wyświetlane.Jeśli witryna jest stosunkowo mała, zwykle zwalnia lub tymczasowo staje się niedostępna. Takiej sytuacji można uniknąć, jeśli treści są udostępniane za pomocą szybkich, wydajnych serwerów z pamięcią podręczną, a SXG – bez konieczności udostępniania kluczy TLS.
Wypróbuj Signed Exchange
Platformy Signed Exchange są dostępne w Chrome 73 i nowszych wersjach. Wcześniej były one dostępne w ramach wersji próbnej origin.
Tworzenie SXG
Aby można było tworzyć obiekty SXG dla swojego źródła (jako wydawcy), potrzebujesz klucza certyfikatu do podpisania podpisu, a certyfikat musi mieć specjalne rozszerzenie „CanSignHttpExchanges”, aby można było przetworzyć go jako prawidłowy SXG. W listopadzie 2018 roku DigiCert to jedyny urząd certyfikacji, który obsługuje to rozszerzenie. Na tej stronie możesz poprosić o certyfikat obsługujący SXG.
Gdy otrzymasz certyfikat SXG, możesz tworzyć własne SXG za pomocą narzędzi do generowania plików referencyjnych opublikowanych na github.
Możesz też zobaczyć przykładowe pliki SXG w repozytorium kodu Chrome (np. to to najprostszy kod utworzony na potrzeby prostego pliku tekstowego). Pamiętaj, że są generowane głównie na potrzeby testów lokalnych i nie oczekuj, że będą miały w podpisie prawidłowe certyfikaty i sygnatury czasowe.
Lokalne testowanie funkcji
Aby utworzyć do testów obiekty SXG, możesz utworzyć samodzielnie podpisany certyfikat i włączyć chrome://flags/#allow-sxg-certs-without-extension, aby przeglądarka Chrome przetwarzała SXG utworzone za pomocą certyfikatu bez specjalnego rozszerzenia.
Jeśli serwer, certyfikat i funkcje SXG są prawidłowo skonfigurowane, powinien działać ten kod:
<!-- 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>
Pamiętaj, że w Chrome 73 i nowszych wersjach przeglądarki SXG są obsługiwane tylko przez tag kotwicy (<a>) i tag link rel=prefetch. Pamiętaj też, że ważność podpisu jest ograniczona do 7 dni na każdą specyfikację, więc podpisane treści stosunkowo szybko tracą ważność.
Przekazywanie opinii
Chętnie poznamy Twoją opinię na temat tego eksperymentu, pisząc na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji lub zgłosić błąd w Chrome. Twoje uwagi bardzo ułatwią proces standaryzacji i rozwiązywanie problemów z wdrażaniem.