このページは Cloud Translation API によって翻訳されました。

nginx を使用して Signed HTTP Exchange（SXG）を配布する方法

nginx を使用して SXG ファイルを取得して提供する方法と、サブリソースプリフェッチの課題

Hiroki Kumazaki

Signed HTTP Exchange（SXG）ディストリビューターは、元のコンテンツ作成者に代わって SXG ファイルを配信できます。SXG をサポートするウェブブラウザでは、このような SXG ファイルはオリジナルのコンテンツ作成者から配信されたかのように表示されます。これにより、プライバシーを侵害することなくクロスサイトプリロードを実装できます。このガイドでは、SXG を適切に配布する方法について説明します。

ブラウザ間のサポート

現在、SXG に対応しているブラウザは Chrome のみです。コンセンサスと最新の情報については、送信元署名 HTTP エクスチェンジの標準化に関するセクションをご覧ください。

SXG ファイルを取得する

サーバーがリクエストとともに SXG ファイルを返すように Accept リクエストヘッダーに指定します。

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

このガイドでは、SXG ファイルを /var/www/sxg に配置していることを前提としています。

シンプルな SXG ファイルを提供する

1 つの SXG ファイルを配布するには、次のヘッダーを添付します。

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

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

新しい構成を nginx に読み込みます。

sudo systemctl restart nginx.service

nginx が SXG ファイルの提供を開始します。 Chrome がサーバーにアクセスすると、コンテンツ配信元のアドレスがバーに表示されます。

サブリソースのプリフェッチ

ほとんどのウェブページは、CSS、JavaScript、フォント、画像などの複数のサブリソースで構成されています。 SXG のコンテンツは、コンテンツ作成者の秘密鍵がないと変更できません。このため、ブラウザがサブリソースを解決しようとしたときに問題が発生します。

たとえば、https://website.test/index.html の index.html.sxg に https://website.test/app.js へのリンクがあるとします。ユーザーのブラウザが https://distributor.test/example.com/index.html.sxg から SXG ファイルを受信すると、https://website.test/app.js へのリンクが見つかります。ブラウザは実際のアクセス時に https://website.test/app.js を直接取得できますが、プライバシー保護のため、プリロードフェーズではこれを実行しないでください。プリロードフェーズ中にリソースがフェッチされた場合、コンテンツ作成者（website.test）は、どのコンテンツ配信会社（distributor.test）がリソースをリクエストしているかを検出できる可能性があります。

dis トリビューター.test/index.html.sxg 内の app.js へのリンクは、website.test/app.js を指しています。

ディストリビューターが独自のサービスから app.js.sxg を提供する場合、https://website.test/app.js をそのサブリソースのディストリビューターのバージョン（https://distributor.test/website.test/app.js.sxg など）に変更しようとすると、署名の不一致が発生し、SXG が無効になります。

distribution.test/index.html.sxg 内の app.js への参照を distribution.test/app.js にリンクしようとすると、署名の不一致が発生します。

この問題を解決するために、Chrome に試験運用版の SXG サブリソースのプリフェッチ機能が追加されました。 about://flags/#enable-sxg-subresource-prefetching で有効にできます。サブリソースのプリフェッチを使用するには、次の条件を満たす必要があります。

ニュースメディアは、link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=" のようなレスポンスヘッダーエントリを SXG に埋め込む必要があります。これは、SXG 固有の完全性ハッシュで置き換えることができるサブリソースを指定します。
ディストリビューターは、SXG を提供するときに link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js" のようなレスポンスヘッダーを添付する必要があります。これは、app.js のパスを指定し、サブリソースに対応します。

アンカー

1 つ目は、nginx-sxg-module で完全性ハッシュを計算し、アップストリームのレスポンスからリンクヘッダーに埋め込むことができるため、比較的簡単です。しかし、2 つ目はコンテンツ配信会社が SXG 内の指定されたサブリソースを認識する必要があるため、より困難です。

https://website.test/app.js 以外のサブリソースがない場合、nginx 構成に追加する必要があるのは以下だけです。

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

しかし、一般的なウェブサイトは多数のサブリソースで構成されているため、このようなケースはめったにありません。また、SXG ファイルを配信する際は、配信会社が適切なアンカーリンクヘッダーを添付する必要があります。現時点では、この問題を簡単に解決する方法はありません。最新情報をお待ちください。

フィードバックを送信

Chromium エンジニアは、SXG の配布に関するフィードバックを webpackage-dev@chromium.org に送信したいと考えており、仕様に関するディスカッションに参加したり、チームにバグを報告したりすることもできます。お寄せいただいたフィードバックは、標準化プロセスや実装に関する問題の解決に大いに役立ちます。ありがとうございました