Cara mendistribusikan Signed HTTP Exchanges (SXG) menggunakan nginx

Cara mendapatkan dan menyajikan file SXG menggunakan nginx, dan tantangan pengambilan data subresource.

Hiroki Kumazaki

Sebagai distributor Signed HTTP Exchanges (SXG), Anda dapat mengirimkan file SXG atas nama kreator konten asli. Browser web yang mendukung SXG akan menampilkan file SXG tersebut seolah-olah file tersebut dikirim dari kreator konten asli. Hal ini memungkinkan Anda menerapkan pramuat lintas situs tanpa melanggar privasi. Panduan ini menunjukkan cara mendistribusikan SXG dengan benar.

Dukungan lintas browser

Saat ini Chrome adalah satu-satunya browser yang mendukung SXG. Lihat Konsensus & Bagian Standardisasi Origin-Signed HTTP Exchange untuk mendapatkan informasi terbaru.

Dapatkan file SXG

Di header permintaan Accept, tentukan bahwa Anda ingin server menampilkan file SXG bersama dengan permintaan tersebut:

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

Panduan ini mengasumsikan bahwa Anda menempatkan file SXG di /var/www/sxg.

Menyajikan file SXG sederhana

Lampirkan header berikut untuk mendistribusikan satu file SXG:

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

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

Muat konfigurasi baru ke nginx:

sudo systemctl restart nginx.service

nginx akan mulai menyajikan file SXG. Saat Chrome mengakses server Anda, alamat penayang konten asli akan muncul pada kolom!

Mengambil subresource

Sebagian besar halaman web terdiri dari beberapa subresource, seperti CSS, JavaScript, font, dan gambar. Konten SXG tidak dapat diubah tanpa kunci pribadi kreator konten. Hal ini menyebabkan masalah saat browser mencoba menyelesaikan subresource.

Misalnya, index.html.sxg dari https://website.test/index.html memiliki link ke https://website.test/app.js. Saat browser pengguna menerima file SXG dari https://distributor.test/example.com/index.html.sxg, browser akan menemukan link ke https://website.test/app.js. Browser dapat mengambil https://website.test/app.js secara langsung pada akses sebenarnya, tetapi hal ini tidak boleh dilakukan dalam fase pramuat untuk menjaga privasi. Jika resource diambil selama fase pramuat, kreator konten (website.test) akan dapat mendeteksi distributor konten (distributor.test) mana yang meminta resource tersebut.

Jika distributor ingin menayangkan app.js.sxg dari layanannya sendiri dan mencoba mengubah https://website.test/app.js agar menjadi versi distributor dari subresource tersebut (seperti https://distributor.test/website.test/app.js.sxg), hal ini akan menyebabkan ketidakcocokan tanda tangan dan membuat SXG menjadi tidak valid.

Untuk mengatasi masalah ini, kini terdapat fitur pengambilan data subresource SXG eksperimental di Chrome. Anda dapat mengaktifkannya di: about://flags/#enable-sxg-subresource-prefetching. Untuk menggunakan pengambilan data subresource, kondisi berikut harus terpenuhi:

• Penayang harus menyematkan entri header respons di SXG, seperti: link: <https://website.test/app.js>;rel="preload";as="script",<https://website.test/app.js>;rel="allowed-alt-sxg";header-integrity="sha256-h6GuCtTXe2nITIHHpJM+xCxcKrYDpOFcIXjihE4asxk=". Tindakan ini menentukan subresource yang dapat diganti dengan hash integritas khusus SXG.
• Distributor harus melampirkan header respons saat menayangkan SXG, seperti: link: <https://distributor.test/website.test/app.js.sxg>;rel="alternate";type="application/signed-exchange;v=b3";anchor="https://website.test/app.js". Kode ini menentukan jalur app.js dan sesuai dengan subresource.

Yang pertama relatif mudah karena nginx-sxg-module dapat menghitung hash integritas dan menyematkannya ke header link dari respons upstream. Namun, yang kedua lebih sulit karena distributor konten harus mengetahui subresource yang ditentukan di SXG.

Jika tidak ada subresource selain https://website.test/app.js, yang perlu Anda tambahkan dalam konfigurasi nginx adalah:

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

Namun, kasus seperti itu jarang terjadi karena {i>website<i} pada umumnya memiliki banyak sub-sumber daya. Selain itu, distributor harus melampirkan header link anchor yang sesuai saat menayangkan file SXG. Saat ini, belum ada cara mudah untuk menyelesaikan masalah ini. Jadi, nantikan kabar terbarunya.

Kirim masukan

Engineer Chromium menantikan masukan Anda tentang pendistribusian SXG di webpackage-dev@chromium.org. Anda juga dapat bergabung dalam diskusi spesifikasi, atau melaporkan bug ke tim. Masukan Anda akan sangat membantu proses standardisasi dan juga membantu mengatasi masalah penerapan. Terima kasih!