인터넷 엔지니어링 태스크 포스 (IETF)

P. Meenan, Editor

의견 요청: 9842

Google LLC

카테고리: 표준 트랙

Y. Weiss, Editor

ISSN: 2070-1721

Shopify Inc.

2025년 9월

압축 사전 전송

초록

이 문서는 하이퍼텍스트 전송 프로토콜(HTTP)에서 사전 기반 압축을 위한 메커니즘을 규정합니다. 이 기법을 활용함으로써 클라이언트와 서버는 전송되는 데이터의 크기를 줄여 성능 향상과 대역폭 소비 감소를 달성할 수 있습니다. 본 문서는 기존 HTTP 압축 방법을 확장하고 HTTP 프로토콜 내에서 압축 사전의 전달 및 사용에 대한 지침을 제공합니다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 문서입니다.

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 발행 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 7841의 섹션 2를 참조하십시오.

이 문서의 현재 상태, 정오표, 피드백 제공 방법에 관한 정보는 https://www.rfc-editor.org/info/rfc9842에서 확인할 수 있습니다.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

1. 소개
- 1.1. 사용 사례
  - 1.1.1. 버전 업그레이드
  - 1.1.2. 공통 콘텐츠
- 1.2. 표기 규약
2. 사전 협상
- 2.1. Use-As-Dictionary
  - 2.1.1. "match"
  - 2.1.2. "match-dest"
  - 2.1.3. "id"
  - 2.1.4. "type"
  - 2.1.5. 예시
- 2.2. Available-Dictionary
- 2.3. Dictionary-ID
3. "compression-dictionary" 링크 관계 타입
4. 사전 압축된 Brotli
5. 사전 압축된 Zstandard
6. 콘텐츠 인코딩 협상
- 6.1. Accept-Encoding
- 6.2. Content-Encoding
7. IANA 고려사항
8. 호환성 고려사항
9. 보안 고려사항
- 9.1. 콘텐츠 변경
- 9.2. 콘텐츠 읽기
- 9.3. 보안 완화책
  - 9.3.1. 교차 출처 보호
  - 9.3.2. 응답 가독성
  - 9.3.3. 서버 책임
10. 프라이버시 고려사항
11. 참고문헌
- 11.1. 규범적 참고문헌
- 11.2. 비규범적 참고문헌
저자 주소

1. 소개

이 명세서는 지정된 HTTP [HTTP] 응답을, 향후 HTTP 응답에서 외부 사전으로 사용하도록 하는 메커니즘을 정의합니다. 이는 외부 사전을 사용할 수 있는 압축 방식(e.g., Brotli [RFC7932] 및 Zstandard [ZSTD])에 적용됩니다.

이 문서는 사전 사용 협상을 위해 사용하는 HTTP 헤더를 설명하고, 협상된 사전을 사용하는 Brotli 및 Zstandard 압축을 위한 content-encoding 값을 등록합니다.

사전 사용 협상은 HTTP의 콘텐츠 협상(참조 RFC 9110 섹션 12)을 활용하며 모든 버전의 HTTP에서 사용할 수 있습니다.

1.1. 사용 사례

어떤 HTTP 응답이든 향후 요청을 위한 압축 사전으로 지정될 수 있어 유연성이 큽니다. 자주 관찰되는 두 가지 일반적인 사용 사례를 아래에 설명합니다.

1.1.1. 버전 업그레이드

리소스의 이전 버전을 새 버전의 사전으로 사용하면 변경분을 델타 압축하여 전달할 수 있어, 일반 압축만으로 얻을 수 있는 것보다 훨씬 작은 응답을 얻을 수 있습니다.

예를 들어:

그림 1: 버전 업그레이드 예시

1.1.2. 공통 콘텐츠

여러 리소스가 응답에서 공통 패턴을 공유하는 경우, 그러한 공통 패턴을 포함한 외부 사전을 참조하여 응답에서 해당 패턴을 효과적으로 압축해낼 수 있습니다. 예로는 사이트 전반에 걸친 유사 페이지의 공통 템플릿 HTML이나 API 호출의 공통 키/값 쌍 등이 있습니다.

예를 들어:

그림 2: 공통 콘텐츠 예시

1.2. 표기 규약

이 문서에서 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 표시될 때에 한해 BCP 14 [RFC2119] 및 [RFC8174]에 설명된 대로 해석됩니다.

이 문서는 구문과 파싱을 지정하기 위해 RFC 9651 섹션 3에서 정의한 용어들(예: Dictionary, String, Inner List, Token, Byte Sequence)을 사용합니다.

이 문서는 긴 줄 처리 전략으로 [FOLDING]에 설명된 방식을 사용합니다.

또한 이 문서는 [HTTP] 및 [HTTP-CACHING]의 용어를 사용합니다.

2. 사전 협상

2.1. Use-As-Dictionary

서버는 HTTP 요청에 응답할 때 해당 응답이 향후 특정 규칙에 맞는 URL 요청들에 대해 사전으로 사용될 수 있음을 "Use-As-Dictionary" 응답 헤더로 광고할 수 있습니다.

"Use-As-Dictionary" 응답 헤더는 Structured Field [STRUCTURED-FIELDS] 형식의 Dictionary로, "match", "match-dest", "id", 및 "type" 값을 가집니다.

2.1.1. "match"

"Use-As-Dictionary" 응답 헤더의 "match" 값은 요청 매칭에 사용할 URL 패턴을 제공하는 String 값입니다(참조 [URLPATTERN]).

매칭에 사용되는 URL 패턴은 정규 표현식 사용을 지원하지 않습니다.

주어진 String 값이 정규 표현식을 사용하지 않고 사전과 동일한 Origin에 해당하는 유효한 URL 패턴인지 검증하기 위해 다음 알고리즘을 사용합니다. 유효한 패턴이면 TRUE를, 잘못된 패턴이면 FALSE를 반환합니다.

MATCH를 해당 사전의 "match" 값으로 둡니다.
URL을 사전 요청의 URL로 둡니다.
PATTERN을 input=MATCH 및 baseURL=URL로 하여 "create a URL pattern" 절차를 실행해 만든 "URL pattern struct"로 둡니다 (참조 URLPATTERN 섹션 1.4).
PATTERN에 대해 "has regexp groups" 검사 결과가 TRUE이면 FALSE를 반환합니다.
TRUE를 반환합니다.

"match" 값은 필수이며, 사전이 유효하다고 간주되기 위해 "Use-As-Dictionary" 응답 헤더에 반드시 포함되어야 합니다.

HTTP 수준에서 지정된 match 패턴은 URL 경로의 퍼센트 인코딩된 버전에서 작동합니다(참조 RFC 3986 섹션 2).

예를 들어 URL "http://www.example.com/düsseldorf"는 "http://www.example.com/d%C3%BCsseldorf"로 인코딩되며 관련 매칭 패턴은 다음과 같습니다:

Use-As-Dictionary: match="/d%C3%BCsseldorf"

2.1.2. "match-dest"

"Use-As-Dictionary" 응답 헤더의 "match-dest" 값은 String 값들의 Inner List로, 해당 사전이 매칭될 Fetch 요청의 destinations 목록을 제공합니다(참조 Fetch의 "RequestDestination", [FETCH]).

"match-dest"가 빈 리스트이면 모든 destination에 매치되어야 합니다.

요청 destination을 지원하지 않는 클라이언트는 "match-dest"를 빈 리스트로 처리하고 모든 destination에 매치해야 합니다.

"match-dest" 값은 선택적이며 기본값은 빈 리스트입니다.

2.1.3. "id"

"Use-As-Dictionary" 응답 헤더의 "id" 값은 사전에 대한 서버 식별자를 지정하는 String 값입니다. "id" 값이 존재하고 길이가 0보다 크면, 클라이언트는 동일한 사전에 대해 "Available-Dictionary" 요청 헤더를 보낼 때 "Dictionary-ID" 요청 헤더에 저장된 "id"를 전송해야 합니다(참조 섹션 2.2).

서버 식별자는 클라이언트에 의해 불투명한 문자열로 취급되어야 합니다.

서버는 식별자만으로 사전 내용을 보증해서는 안 되며, 사전 해시를 검증한 후에만 사용해야 합니다.

"id" 값 문자열 길이(디코딩 후)는 최대 1024자를 지원합니다.

"id" 값은 선택적이며 기본값은 빈 문자열입니다.

2.1.4. "type"

"Use-As-Dictionary" 응답 헤더의 "type" 값은 제공된 사전의 파일 형식을 설명하는 Token 값입니다.

"raw"는 포맷화되지 않은 바이트 덩어리로서 어떤 압축 방식에도 적합한 사전 형식으로 정의됩니다.

클라이언트가 이해하지 못하는 타입의 사전을 수신한 경우, 클라이언트는 해당 사전을 사용해서는 안 됩니다.

"type" 값은 선택적이며 기본값은 "raw"입니다.

2.1.5. 예시

2.1.5.1. 경로 접두사

다음과 같은 응답 헤더를 포함한 응답은 동일한 Origin의 요청에 대해 경로 접두사 /product/ 를 가진 모든 문서 요청에 매칭됨을 지정합니다(참조 RFC 9110 섹션 4.3.1).

NOTE: '\' line wrapping per RFC 8792

Use-As-Dictionary: \
  match="/product/*", match-dest=("document")

2.1.5.2. 버전 디렉터리

다음과 같은 응답 헤더는 "/app/"로 시작하고 "/main.js"로 끝나는 모든 경로와 매칭됩니다:

Use-As-Dictionary: match="/app/*/main.js"

2.2. Available-Dictionary

클라이언트가 적절한 사전을 보유하고 있는 리소스를 요청할 때, 해당 클라이언트는 사용 가능한 사전이 있음을 서버에 알리기 위해 "Available-Dictionary" 요청 헤더를 추가할 수 있습니다.

"Available-Dictionary" 요청 헤더는 단일 사용 가능한 사전의 내용에 대한 SHA-256 해시를 포함하는 Structured Field [STRUCTURED-FIELDS] Byte Sequence입니다.

클라이언트는 가장 적합한 단일 매칭을 위해 단 하나의 "Available-Dictionary" 요청 헤더만을 전송해야 합니다.

예시:

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:

2.2.1. 사전 신선도 요구사항

매칭으로 간주되려면, 사전 리소스는 신선해야 하거나(참조 [HTTP-CACHING]) 허용되는 범위 내에서 오래된(stale) 상태로 제공될 수 있어야 합니다(참조 [RFC5861]).

2.2.2. 사전 URL 매칭

"Use-As-Dictionary" 지시의 결과로 저장된 사전은 "match" 문자열과 선택적 "match-dest" 문자열을 포함하며, 이는 클라이언트의 발신 요청을 사용 가능한 사전과 매칭하는 데 사용됩니다.

발신 요청이 주어진 사전과 매치되는지 확인하기 위해 다음 알고리즘은 성공적인 매치에 대해 TRUE를, 매치 실패에 대해 FALSE를 반환합니다:

클라이언트가 요청 destination을 지원하고 사전에 "match-dest" 문자열이 제공된 경우:
- DEST를 해당 사전의 "match-dest" 값으로 둡니다.
- REQUEST_DEST를 현재 요청의 destination 값으로 둡니다.
- 만약 DEST가 빈 리스트가 아니고 REQUEST_DEST가 DEST 리스트에 포함되지 않으면 FALSE를 반환합니다.
BASEURL을 사전 요청의 URL로 둡니다.
URL을 검사 대상 발신 요청의 URL로 둡니다.
BASEURL의 Origin과 URL의 Origin이 동일하지 않으면 FALSE를 반환합니다(참조 RFC 9110 섹션 4.3.1).
MATCH를 해당 사전의 "match" 값으로 둡니다.
PATTERN을 input=MATCH 및 baseURL=URL로 하여 "create a URL pattern" 절차를 실행해 만든 "URL pattern struct"로 둡니다.
PATTERN에 대해 input=URL로 "match" 단계를 실행한 결과를 반환합니다(요청 URL과 "match" 문자열 간의 매칭을 검사함).

2.2.3. 다중 매칭 사전

주어진 요청 URL에 대해 여러 사전이 매칭되는 경우, 클라이언트는 다음 규칙을 사용해 단일 사전을 선택해야 합니다:

요청 destination을 지원하는 클라이언트의 경우, "match-dest"를 지정하고 매칭하는 사전이 목적지 미지정 매치보다 우선합니다.
동일한 목적지 우선순위라면, "match"가 가장 긴 사전이 우선합니다.
목적지 및 match 길이가 동등하다면, 가장 최근에 가져온 사전이 우선합니다.

2.3. Dictionary-ID

클라이언트가 적절한 사전을 보유하고 있고 그 사전이 "Use-As-Dictionary" 응답 헤더에 서버가 제공한 "id"로 저장된 경우, 클라이언트는 향후 해당 사전에 매칭되는 요청을 보낼 때 저장된 "id"를 "Dictionary-ID" 요청 헤더에 반영해야 합니다.

"Dictionary-ID" 요청 헤더는 Structured Field [STRUCTURED-FIELDS] String이며(디코딩 후) 최대 1024자를 지원하고, 서버가 제공한 "id"와 동일해야 합니다.

예를 들어, 다음과 같이 사전 ID를 설정한 HTTP 응답이 있다고 가정하면:

Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"

이후 해당 사전에 매치되는 요청은 해시와 ID를 모두 포함합니다:

Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345"

3. "compression-dictionary" 링크 관계 타입

이 명세서는 현재 HTTP 응답과 관련되어 있지만 현재 응답에서 직접 사용되지는 않는 압축 사전의 URL을 제공하기 위한 메커니즘을 제공하는 "compression-dictionary" 링크 관계 타입을 정의합니다([WEB-LINKING]).

"compression-dictionary" 링크 관계 타입은 지정된 리소스를 가져와 캐시하는 것이 향후 요청에 유익할 가능성이 높음을 나타냅니다. 이러한 향후 요청의 일부 응답은 지정된 리소스를 압축 사전으로 사용할 수 있습니다.

클라이언트는 적절하다고 판단되는 시점에 제공된 리소스를 가져올 수 있습니다.

압축 사전을 가져오려면 해당 응답에 "Use-As-Dictionary" 응답 헤더와 캐싱 응답 헤더가 포함되어야 사전으로 사용할 수 있습니다. 링크 관계는 사전의 가져오기를 트리거하는 메커니즘만 제공합니다.

다음 예는 https://example.org/dict.dat 에 있는 리소스를 가리키는 링크로서 압축 사전 생성이 예상됨을 보여줍니다:

Link: <https://example.org/dict.dat>; rel="compression-dictionary"

4. 사전 압축된 Brotli

"dcb" 콘텐츠 인코딩은 "Dictionary-Compressed Brotli" 스트림을 식별합니다.

"Dictionary-Compressed Brotli" 스트림은 고정 헤더가 뒤따르는 Shared Brotli [SHARED-BROTLI] 스트림으로 구성됩니다. 헤더는 4바이트 고정 시퀀스와 사용된 외부 사전의 32바이트 해시로 이루어집니다. Shared Brotli 스트림은 참조된 외부 사전과 최대 16MB 크기의 압축 윈도우를 사용하여 생성됩니다.

"dcb" 콘텐츠 인코딩에 사용되는 사전은 섹션 2.1.4에서 정의된 "raw" 사전 타입이며, [SHARED-BROTLI]의 섹션 8.2에서 정의된 접두사 사전(prefix dictionary)으로 처리됩니다.

36바이트 고정 헤더는 다음과 같습니다:

Magic_Number:: 고정 4바이트 -- 0xff, 0x44, 0x43, 0x42.
SHA_256_Hash:: 32바이트. 사전의 SHA-256 해시 다이제스트.

dcb 콘텐츠 인코딩을 지원한다고 선언하는 클라이언트는 최대 16MB의 윈도우 크기로 압축된 리소스를 해제할 수 있어야 합니다.

Brotli 압축에서는 전체 사전이 압축/해제 동안 압축 윈도우와 무관하게 사용 가능하므로, 압축 윈도우보다 큰 리소스에 대해서도 델타 압축이 가능합니다.

5. 사전 압축된 Zstandard

"dcz" 콘텐츠 인코딩은 "Dictionary-Compressed Zstandard" 스트림을 식별합니다.

"Dictionary-Compressed Zstandard" 스트림은 40바이트 고정 헤더로 시작하고, 이어서 외부 사전으로 압축된 Zstandard [ZSTD] 스트림이 옵니다.

"dcz" 콘텐츠 인코딩에 사용되는 사전은 섹션 2.1.4에서 정의된 "raw" 타입이며, [ZSTD]의 섹션 5에 따라 raw 사전으로 처리됩니다.

40바이트 헤더는 8바이트 고정 시퀀스와 이어서 사용된 외부 사전의 32바이트 SHA-256 해시로 구성됩니다:

Magic_Number:: 8바이트 고정 -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.
SHA_256_Hash:: 32바이트. 사전의 SHA-256 해시 다이제스트.

40바이트 헤더는 Zstandard 스킵가능 프레임(little-endian 0x184D2A5E)에 32바이트 길이(little-endian 0x00000020)를 가진 형태로 기존 Zstandard 디코더와 호환됩니다.

dcz 콘텐츠 인코딩을 지원한다고 선언하는 클라이언트는 최소 8MB 또는 사전 크기의 1.25배 중 큰 값(최대 128MB까지)의 윈도우 크기로 압축된 리소스를 해제할 수 있어야 합니다.

사용된 윈도우 크기는 콘텐츠에 인코딩되며(현재는 2의 거듭제곱으로만 표현 가능), 이 값은 위 제한보다 작아야 합니다. 구현체는 이 제한을 초과하는 윈도우 크기를 디코딩 오류로 처리할 수 있습니다.

Zstandard 압축에서는 입력 크기가 압축 윈도우를 초과할 때까지 전체 사전이 압축/해제 동안 사용 가능합니다. 그 지점을 넘으면 사전은 더 이상 사용 불가능해집니다. 사전 크기의 1.25배 윈도우를 사용하면, 릴리스 간에 리소스가 25% 증가한 경우에도 완전한 델타 압축이 가능하면서 클라이언트가 해당 응답을 위해 할당할 메모리를 제어할 수 있게 됩니다.

6. 콘텐츠 인코딩 협상

특정 요청에 대해 압축 사전을 사용하여 응답을 압축할 수 있을 때, 사용될 인코딩은 "Accept-Encoding" 요청 헤더와 "Content-Encoding" 응답 헤더를 통한 HTTP의 일반적인 콘텐츠 인코딩 협상 메커니즘으로 협상됩니다.

사용할 사전은 별도로 협상되며 "Available-Dictionary" 요청 헤더에 광고됩니다.

6.1. Accept-Encoding

클라이언트가 주어진 요청에 대해 사용할 사전을 보유하고 있고 사전 기반 콘텐츠 인코딩을 사용하기로 결정하면, 클라이언트는 지원하는 사전 인식 콘텐츠 인코딩들을 "Accept-Encoding" 요청 헤더에 추가합니다. 예를 들면:

Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz

클라이언트가 요청에 대해 저장된 사전이 없거나 사전 사용을 선택하지 않는 경우, 클라이언트는 "Accept-Encoding" 요청 헤더에 사전 인식 콘텐츠 인코딩을 보내서는 안 됩니다.

6.2. Content-Encoding

서버가 클라이언트가 광고한 사전 인코딩 중 하나를 지원하고 클라이언트가 광고한 사전을 사용해 응답을 압축하기로 선택하면, 서버는 선택된 알고리즘에 해당하는 값으로 "Content-Encoding" 응답 헤더를 설정합니다. 예:

Content-Encoding: dcb

응답이 캐시 가능하면, 캐시가 사전-압축된 리소스를 지원하지 않는 클라이언트에게 제공하거나 잘못된 사전으로 압축된 응답을 제공하지 못하도록 "Vary" 헤더를 포함해야 합니다. 예:

Vary: accept-encoding, available-dictionary

7. IANA 고려사항

7.1. 콘텐츠 인코딩 등록

IANA는 다음 항목을 "HTTP Content Coding Registry"에 추가했습니다:

Name:: dcb
Description:: "Dictionary-Compressed Brotli" 데이터 형식.
Reference:: RFC 9842, 섹션 4

Name:: dcz
Description:: "Dictionary-Compressed Zstandard" 데이터 형식.
Reference:: RFC 9842, 섹션 5

7.2. 헤더 필드 등록

IANA는 다음 항목을 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 추가했습니다:

Table 1
Field Name	Status	Reference
Use-As-Dictionary	permanent	RFC 9842, 섹션 2.1
Available-Dictionary	permanent	RFC 9842, 섹션 2.2
Dictionary-ID	permanent	RFC 9842, 섹션 2.3

7.3. 링크 관계 등록

IANA는 다음 항목을 "Link Relation Types" 레지스트리에 추가했습니다:

Relation Name:: compression-dictionary
Description:: 콘텐츠 인코딩에 사용되는 압축 사전을 가리킴.
Reference:: RFC 9842, 섹션 3

8. 호환성 고려사항

네트워크 경로상에 HTTP 요청을 가로채고 검사 및 처리하는 장치들(웹 프록시, 방화벽, 침입 탐지 시스템 등)이 존재하는 것은 흔한 일입니다. 이러한 장치들이 사전 압축 응답을 잘못 처리할 위험을 최소화하기 위해, 압축 사전 전송은 보안 컨텍스트(HTTPS)에서만 사용되어야 합니다.

9. 보안 고려사항

Brotli, Shared Brotli 및 Zstandard에 대한 기존 보안 고려사항이 사전 기반 버전에도 적용됩니다.

9.1. 콘텐츠 변경

사전은 콘텐츠와 동일한 보안 주의사항으로 다뤄져야 합니다. 사전의 변경은 압축 해제된 콘텐츠 변경으로 이어질 수 있습니다.

사전은 콘텐츠의 SHA-256 해시로 검증되어 클라이언트와 서버가 동일한 사전을 사용하는지 확인합니다. SHA-256의 강도는 사전이 동일 출처(origin)에서 제공되므로 공격을 막기 위한 명시적 필요성은 크지 않지만, 추후 다른 해시 알고리즘 사용 필요가 있으면 "Use-As-Dictionary" 응답 헤더를 확장하여 다른 알고리즘을 지정할 수 있습니다.

9.2. 콘텐츠 읽기

RFC 7457의 압축 관련 공격들은 공개 데이터와 비공개 데이터가 섞여 압축되는 것은 위험하다는 것을 보여줍니다. 데이터 소스에는 압축된 데이터뿐 아니라 사전도 포함됩니다. 예를 들어 비밀 쿠키가 공개 데이터 전용 사전으로 압축되면 쿠키에 대한 정보가 유출될 수 있습니다.

사전은 압축된 데이터에 대한 정보를 드러낼 수 있고 그 반대도 성립합니다. 즉, 공격자가 압축되는 데이터의 일부를 제어하고 압축된 크기를 관찰할 수 있으면 사전 내용을 추론할 수 있고, 반대로 공격자가 사전을 제어하면 압축된 데이터에 대한 정보를 얻을 수 있습니다.

9.3. 보안 완화책

완화책이 통과하지 못하면, 클라이언트는 응답을 버리고 오류를 반환해야 합니다.

9.3.1. 교차 출처 보호

사전이 제공된 동일 출처의 콘텐츠에만 영향을 미치도록 보장하기 위해, 사전을 요청과 매칭하는 데 사용되는 URL 패턴(섹션 2.1.1)은 사전이 제공된 동일한 출처에 속하도록 보장됩니다.

9.3.2. 응답 가독성

브라우저와 같은 클라이언트는 응답 페이로드의 가독성과 사용자 추적에 대해 추가 보호를 제공하므로, 사전 기반 압축 사용이 공개되지 않아야 할 정보를 드러내지 않도록 추가 보호 조치를 취해야 합니다.

이러한 경우 사전 압축은 사전과 압축된 응답이 클라이언트에 의해 완전히 읽을 수 있는 경우에만 사용되어야 합니다.

브라우저 관점에서는, 이는 사전과 압축된 응답이 동시 출처(same-origin)이거나 교차 출처일 경우 CORS 검사를 통과해야 함을 의미합니다(참조 Fetch의 CORS 체크 섹션 4.9).

9.3.3. 서버 책임

사전의 일부를 공격자가 제어하거나 사전을 읽을 수 있고 압축되는 콘텐츠의 일부를 제어할 수 있는 경우 타이밍 공격이 발생할 수 있습니다. 이런 공격에서 응답의 크기나 처리 시간의 변화는 내용에 대한 정보를 유출할 수 있습니다.

일반적으로 서버는 동일 콘텐츠에 대해 여러 사전의 활성 사용을 금지하거나, 제어 불가능한 소스에서 오는 콘텐츠가 포함되면 압축을 비활성화하는 등 요청별 변이를 방지하여 이러한 공격을 완화할 수 있습니다. 또한 사전 콘텐츠에 대한 접근과 제어를 응답 콘텐츠와 동일한 수준으로 보호해야 합니다. 추가로, 클라이언트가 교차 출처 요청 컨텍스트를 나타내는 CORS 관련 요청 헤더를 제공하는 경우 서버가 사전 인식 압축을 비활성화하도록 하기 위한 요구사항들이 있습니다.

다음 알고리즘은 교차 출처 요청에 대해 FALSE를 반환하며, 이러한 경우 사전 기반 압축 사용을 피해야 합니다:

"Sec-Fetch-Site" 요청 헤더가 없으면 TRUE를 반환합니다.
"Sec-Fetch-Site" 값이 "same-origin"이면 TRUE를 반환합니다.
"Sec-Fetch-Mode" 요청 헤더가 없으면 TRUE를 반환합니다.
"Sec-Fetch-Mode" 값이 "navigate" 또는 "same-origin"이면 TRUE를 반환합니다.
"Sec-Fetch-Mode" 값이 "cors"인 경우:
- 응답에 "Access-Control-Allow-Origin" 응답 헤더가 없으면 FALSE를 반환합니다.
- 요청에 "Origin" 요청 헤더가 없으면 FALSE를 반환합니다.
- "Access-Control-Allow-Origin" 응답 헤더 값이 "*"이면 TRUE를 반환합니다.
- "Access-Control-Allow-Origin" 응답 헤더 값이 "Origin" 요청 헤더 값과 일치하면 TRUE를 반환합니다.
FALSE를 반환합니다.

10. 프라이버시 고려사항

사전은 사전 콘텐츠의 해시를 사용하여 향후 요청에서 광고되므로 사전이 추적 쿠키로 악용될 가능성이 있습니다.

추가적인 추적 우려를 완화하기 위해, 클라이언트는 사전을 쿠키를 처리하는 방식과 동일하게 취급해야 합니다. 이는 쿠키에 사용하는 것과 동일하거나 더 엄격한 파티셔닝을 사용하여 저장소를 분할하고, 쿠키가 지워질 때 사전도 함께 지우는 것을 포함합니다.

11. 참고문헌

11.1. 규범적 참고문헌

[FETCH]: WHATWG, “Fetch Standard”, WHATWG Living Standard, <https://fetch.spec.whatwg.org/>.
Commit snapshot: <https://fetch.spec.whatwg.org/commit-snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/>
[FOLDING]: Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.
[HTTP-CACHING]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Caching”, RFC 9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[HTTP]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, RFC 9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]: Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHA-256]: Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, RFC 6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[SHARED-BROTLI]: Alakuijala, J., Duong, T., Kliuchnikov, E., Szabadka, Z., and L. Vandevenne, Ed., “Shared Brotli Compressed Data Format”, RFC 9841, September 2025, <https://www.rfc-editor.org/info/rfc9841>.
[STRUCTURED-FIELDS]: Nottingham, M. and P-H. Kamp, “Structured Field Values for HTTP”, RFC 9651, September 2024, <https://www.rfc-editor.org/info/rfc9651>.
[URLPATTERN]: WHATWG, “URL Pattern Standard”, WHATWG Living Standard, <https://urlpattern.spec.whatwg.org/>.
[URL]: Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[WEB-LINKING]: Nottingham, M., “Web Linking”, RFC 8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[ZSTD]: Collet, Y. and M. Kucherawy, Ed., “Zstandard Compression and the 'application/zstd' Media Type”, RFC 8878, February 2021, <https://www.rfc-editor.org/info/rfc8878>.

11.2. 비규범적 참고문헌

[RFC5861]: Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”, RFC 5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.
[RFC6265]: Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[RFC7457]: Sheffer, Y., Holz, R., and P. Saint-Andre, “Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)”, RFC 7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7932]: Alakuijala, J. and Z. Szabadka, “Brotli Compressed Data Format”, RFC 7932, July 2016, <https://www.rfc-editor.org/info/rfc7932>.

저자 주소

Patrick Meenan (editor)
Google LLC
EMail: pmeenan@google.com

Yoav Weiss (editor)
Shopify Inc.
EMail: yoav.weiss@shopify.com