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

Jak pobierać i przekazywać pliki SXG za pomocą nginx oraz jakie problemy wiążą się z pobieraniem zasobów wstępnie z wyprzedzeniem.

Hiroki Kumazaki
Hiroki Kumazaki
X GitHub

Jako dystrybutor podpisanej wymiany HTTP (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 tak, jakby zostały dostarczone przez twórców oryginalnych treści. Dzięki temu możesz wdrożyć wstępne wczytywanie z innych witryn bez naruszania prywatności. Z tego przewodnika dowiesz się, jak prawidłowo rozpowszechniać SXG.

Obsługa w różnych przeglądarkach

Obecnie Chrome to jedyna przeglądarka, która obsługuje SXG. Aby uzyskać aktualne informacje, zapoznaj się z sekcją Konsensus i standardy w artykule Giełdy HTTP z podpisami źródłowymi.

Pobieranie plików SXG

W nagłówku żądania Accept określ, że serwer ma zwrócić plik SXG wraz z żądaniem:

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

W tym przewodniku zakładamy, że pliki SXG znajdują się w folderze /var/www/sxg.

Przesyłanie prostego pliku SXG

Aby rozpowszechnić pojedynczy 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;
    }
    ...

Załaduj nową konfigurację do nginx:

sudo systemctl restart nginx.service

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

Wstępnie pobieraj zasoby podrzędne

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

Załóżmy na przykład, że adres 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 adresu https://distributor.test/example.com/index.html.sxg, znajdzie link do adresu https://website.test/app.js. Przeglądarka może pobierać dane https://website.test/app.js bezpośrednio w momencie uzyskania dostępu, ale nie powinno się tego robić na etapie wstępnego wczytania, aby zachować prywatność. Jeśli zasób został pobrany na etapie wstępnego wczytywania, twórca treści (website.test) mógł określić, który dystrybutor treści (distributor.test) go żąda.

Link do pliku app.js w pliku distributor.test/index.html.sxg wskazuje na stronę website.test/app.js.

Jeśli dystrybutor chce wyświetlać app.js.sxg ze swojej usługi i próbuje zmienić https://website.test/app.js na wersję tego zasobu podrzędnego, np. https://distributor.test/website.test/app.js.sxg, spowoduje to niezgodność podpisu i unieważnienie SXG.

Próba powiązania odniesienia do app.js z adresem distributor.test/index.html.sxg do pliku distributor.test/app.js powoduje niezgodność podpisu.

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

  • Wydawca musi umieścić w SXG wpis z nagłówkiem 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 on zasób podrzędny, który można zastąpić specyficznym ciągiem znaków integralności SXG.
  • Dystrybutor musi dołączyć nagłówek odpowiedzi, gdy udostępnia SXG, 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 zasobowi podrzędnemu.

anchor

Pierwsza z nich jest stosunkowo łatwa, ponieważ nginx-sxg-module może obliczać sumy kontrolne integralności i umieszczać je w nagłówkach linków z odpowiedzi upstream. Druga opcja jest trudniejsza, ponieważ dystrybutor treści musi znać określone zasoby podrzędne w SXG.

Jeśli nie ma żadnych zasobów podrzędnych innych niż https://website.test/app.js, musisz tylko dodać 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 zasobów podrzędnych. Dodatkowo dystrybutor musi dołączyć odpowiedni nagłówek linku kotwicy podczas wyświetlania pliku SXG. Obecnie nie ma łatwego sposobu na rozwiązanie tego problemu, więc bądź na bieżąco z aktualizacjami.

Prześlij opinię

Inżynierowie Chromium chętnie poznają Twoją opinię na temat dystrybucji SXG. Napisz do nich na adres webpackage-dev@chromium.org. Możesz też dołączyć do dyskusji na temat specyfikacji lub zgłosić błąd zespołowi. Twoja opinia znacznie ułatwi proces standaryzacji i pomoże rozwiązać problemy z wdrażaniem. Dziękujemy!