nginx를 사용하여 서명된 HTTP 교환 (SXG)을 배포하는 방법

nginx를 사용하여 SXG 파일을 가져오고 제공하는 방법과 하위 리소스 미리 가져오기의 과제

Hiroki Kumazaki

서명된 HTTP 교환 (SXG) 배급사는 원본 콘텐츠 크리에이터를 대신하여 SXG 파일을 전송할 수 있습니다. SXG를 지원하는 웹브라우저에서는 이러한 SXG 파일을 원본 콘텐츠 크리에이터가 제공한 것처럼 표시합니다. 이를 통해 개인 정보 보호를 위반하지 않으면서 크로스 사이트 미리 로드를 구현할 수 있습니다. 이 가이드에서는 SXG를 올바르게 배포하는 방법을 설명합니다.

교차 브라우저 지원

Chrome은 현재 SXG를 지원하는 유일한 브라우저입니다. 합의 및 Origin-Signed HTTP Exchanges의 표준화 섹션에서 최신 정보를 확인하세요.

SXG 파일 가져오기

서버가 요청과 함께 SXG 파일을 반환하도록 Accept 요청 헤더에 지정합니다.

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

이 가이드에서는 SXG 파일을 /var/www/sxg에 넣었다고 가정합니다.

간단한 SXG 파일 제공

다음 헤더를 연결하여 단일 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)를 감지할 수 있습니다.

배급사가 자체 서비스에서 app.js.sxg를 제공하려고 하고 https://website.test/app.js를 해당 하위 리소스 (예: https://distributor.test/website.test/app.js.sxg)의 배급사 버전이 되도록 수정하려고 하면 서명 불일치가 발생하고 SXG가 무효화됩니다.

이 문제를 해결하기 위해 현재 Chrome에 실험용 SXG 하위 리소스 미리 가져오기 기능이 있습니다. about://flags/#enable-sxg-subresource-prefetching에서 사용 설정할 수 있습니다. 하위 리소스 미리 가져오기를 사용하려면 다음 조건을 충족해야 합니다.

• 게시자는 SXG에 응답 헤더 항목(예: 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를 게재할 때 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의 경로를 지정하며 하위 리소스에 해당합니다.

첫 번째 방법은 비교적 쉽습니다. nginx-sxg-module가 무결성 해시를 계산하여 업스트림 응답의 링크 헤더에 삽입할 수 있기 때문입니다. 그러나 두 번째 방법은 더 어렵습니다. 콘텐츠 배급사가 SXG에 지정된 하위 리소스를 알고 있어야 하기 때문입니다.

https://website.test/app.js 외에 하위 리소스가 없는 경우 nginx 구성에 추가하면 됩니다.

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

그러나 일반적인 웹사이트는 많은 하위 리소스로 구성되기 때문에 이러한 경우는 드뭅니다. 또한 배포자는 SXG 파일을 제공할 때 적절한 앵커 링크 헤더를 첨부해야 합니다. 현재로서는 이 문제를 쉽게 해결할 수 있는 방법이 없으므로 최신 소식을 계속해서 확인해 주시기 바랍니다.

의견 보내기

Chromium 엔지니어는 webpackage-dev@chromium.org를 통해 SXG 배포에 관한 의견을 듣고자 합니다. 사양 토론에 참여하거나 팀에 버그를 신고할 수도 있습니다. 여러분의 의견은 표준화 과정을 진행하고 구현 문제를 해결하는 데 큰 도움이 됩니다. 감사합니다.