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

Jak pobierać i udostępniać pliki SXG przy użyciu nginx oraz jakie są 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 zostały dostarczone przez twórców oryginalnych treści. Dzięki temu możesz wdrożyć wstępne wczytywanie treści 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. Zobacz konsensus i bardziej aktualne informacje znajdziesz w sekcji poświęconej standaryzacji giełd HTTP podpisanych po stronie źródła.

Pobierz pliki SXG

Określ w nagłówku żądania Accept, że wraz z żądaniem serwer ma zwracać plik SXG:

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

W tym przewodniku przyjęto, że pliki SXG zostały umieszczone w folderze /var/www/sxg.

Udostępnij prosty plik SXG

Aby dystrybuować pojedynczy plik SXG, dołącz następujące nagłówki:

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

Skonfiguruj funkcję 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 folderu 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 oryginalnego 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 usługi https://distributor.test/example.com/index.html.sxg, znajdzie link do adresu https://website.test/app.js. Przeglądarka może pobrać plik https://website.test/app.js bezpośrednio podczas rzeczywistego dostępu, ale ze względu na ochronę prywatności nie powinno się tego robić na etapie wstępnego wczytywania. 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.

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.

Aby rozwiązać ten problem, wprowadziliśmy w Chrome eksperymentalną funkcję pobierania z wyprzedzeniem zasobów podrzędnych SXG. Możesz włączyć na tej stronie: about://flags/#enable-sxg-subresource-prefetching. Aby użyć pobierania z wyprzedzeniem 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 zasób podrzędny, który można zastąpić określonym haszem integralności SXG.
• Jeśli udostępniasz 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 zasobowi podrzędnemu.

Pierwszy jest stosunkowo prosty, ponieważ nginx-sxg-module może obliczać hasze integralności i umieszczać je w nagłówkach linków pochodzących z odpowiedzi nadrzędnych. Drugi jest jednak trudniejszy, ponieważ dystrybutor treści musi znać określone zasoby podrzędne w ramach 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 rzadkością, ponieważ typowe witryny zawierają wiele zasobów podrzędnych. Dodatkowo podczas udostępniania pliku SXG dystrybutor musi dołączyć odpowiedni nagłówek linku do kotwicy. Obecnie nie ma prostego sposobu rozwiązania tego problemu, prosimy więc o cierpliwość.

Prześlij opinię

Inżynierowie Chromium chcą poznać Twoją opinię na temat dystrybucji SXG 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 będzie bardzo przydatna w procesie standaryzacji i rozwiązaniu problemów z implementacją. Dziękujemy!