Jak dystrybuować podpisane wymiany HTTP (SXG) za pomocą nginx

Jak pobierać i udostępniać pliki SXG za pomocą nginx, a także wyzwania związane z wstępnym pobieraniem zasobów podrzędnych.

Hiroki Kumazaki

Jako dystrybutor Signed HTTP Exchange (SXG) możesz dostarczać pliki SXG w imieniu twórców oryginalnych treści. Przeglądarki obsługujące SXG będą wyświetlać takie pliki SXG tak, jakby pochodziły od twórców oryginalnych treści. Pozwala to wdrożyć wstępne wczytywanie z innych witryn bez naruszania prywatności. Z tego przewodnika dowiesz się, jak prawidłowo rozpowszechniać SXG.

Obsługa różnych przeglądarek

Chrome jest obecnie jedyną przeglądarką, która obsługuje SXG. Bardziej aktualne informacje znajdziesz w sekcji „Konsensus i standaryzacja” w artykule Giełdy HTTP z podpisaniem źródła.

Pobierz pliki SXG

W nagłówku żądania Accept określ, że serwer ma zwracać plik SXG razem z tym żądaniem:

Accept: application/signed-exchange;v=b3,*/*;q=0.8

W tym przewodniku zakładamy, że Twoje pliki SXG są umieszczone w usłudze /var/www/sxg.

Udostępnianie prostego pliku SXG

Aby rozpowszechnić jeden plik SXG, dołącz te nagłówki:

Content-Type: application/signed-exchange;v=v3
X-Content-Type-Options: nosniff

Skonfiguruj 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;
    }
    ...

Wczytaj nową konfigurację do instancji nginx:

sudo systemctl restart nginx.service

nginx zacznie obsługiwać pliki SXG. Gdy Chrome uzyska dostęp do serwera, na pasku pojawi się adres wydawcy oryginalnej treści.

Pobieraj z wyprzedzeniem zasoby podrzędne

Większość stron internetowych składa się z wielu zasobów podrzędnych, takich jak CSS, JavaScript, czcionki i obrazy. Treści SXG nie można zmienić bez klucza prywatnego twórcy treści. Powoduje to problemy, gdy przeglądarka próbuje wyświetlić zasoby podrzędne.

Załóżmy na przykład, że index.html.sxg z witryny https://website.test/index.html zawiera link do strony https://website.test/app.js. Gdy przeglądarka użytkownika otrzyma plik SXG z usługi https://distributor.test/example.com/index.html.sxg, znajdzie link do https://website.test/app.js. Przeglądarka może pobierać plik https://website.test/app.js bezpośrednio przy rzeczywistym dostępie, ale nie należy tego robić na etapie wstępnego wczytywania, aby zachować prywatność. Jeśli zasób został pobrany na etapie wstępnego wczytywania, twórca treści (website.test) będzie w stanie określić, który dystrybutor treści (distributor.test) prosi o ten zasób.

Jeśli dystrybutor chce udostępniać app.js.sxg ze swojej usługi i próbuje zmodyfikować https://website.test/app.js, aby był wersją tego zasobu podrzędnego (np. https://distributor.test/website.test/app.js.sxg), spowoduje to niezgodność podpisu i unieważni SXG.

Aby rozwiązać ten problem, wprowadziliśmy w Chrome eksperymentalną funkcję wstępnego pobierania zasobów podrzędnych SXG. Możesz ją włączyć na stronie about://flags/#enable-sxg-subresource-prefetching. Aby korzystać z wstępnego pobierania zasobów podrzędnych, muszą być spełnione te warunki:

• Wydawca musi umieścić w SXG wpis nagłówka odpowiedzi, np. link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Określa zasób podrzędny, który można zastąpić określonym haszem integralności SXG.
• Podczas udostępniania SXG dystrybutor musi dołączyć nagłówek odpowiedzi, np. link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Określa ścieżkę app.js i odpowiada zasóbowi podrzędnemu.

Pierwszy z nich jest stosunkowo prosty, ponieważ nginx-sxg-module może obliczać hasze integralności i umieszczać je w nagłówkach linków z odpowiedzi na żądanie. Drugi jest jednak trudniejszy, ponieważ dystrybutor treści musi wiedzieć o zasobach podrzędnych SXG.

Jeśli nie ma żadnych zasobów podrzędnych innych niż https://website.test/app.js, wystarczy, że dołączysz do konfiguracji nginx:

add_header link <https://distributor.test/website.test/app.js.sxg>;rel="alter...

Takie przypadki są jednak rzadkie, ponieważ typowe witryny składają się z wielu podzasobów. Dodatkowo podczas udostępniania pliku SXG dystrybutor musi dołączyć odpowiedni nagłówek linku kotwiczącego. Obecnie nie ma łatwego sposobu na rozwiązanie tego problemu, więc wkrótce podamy więcej informacji na ten temat.

Prześlij opinię

Inżynierowie Chromium chętnie poznają Twoją opinię na temat dystrybucji SXG, pisząc na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji i zgłosić błąd zespołowi. Twoje uwagi bardzo pomogą w procesie standaryzacji i pomogą rozwiązać problemy z wdrażaniem. Dziękujemy.