HTTPQUERY
한국어

Accept-Encoding

사용법

HTTP Accept-Encoding 요청 헤더는 콘텐츠 협상 과정의 일부로, 클라이언트가 지원하는 인코딩 방식을 지정합니다. 서버는 사용 가능한 방식 중 하나를 선택한 뒤 HTTP 응답에 Content-Encoding 헤더를 포함시켜 그 선택을 클라이언트에 알립니다.

참고

클라이언트와 서버가 같은 인코딩 방식을 지원하더라도 전송 전에 원본 리소스를 전혀 가공하지 않는 경우가 있습니다. 이는 리소스의 identity 값도 받아들일 만한 상황에서 발생합니다. 흔한 예는 데이터가 이미 압축되어 있어 추가 압축 알고리즘을 적용해도 크기가 더 줄지 않는 경우입니다. JPEG처럼 미리 압축된 이미지 파일이 여기에 해당합니다. 또 다른 상황은 서버 부하가 심해 전송 전 데이터를 가공할 자원을 할애할 수 없는 경우입니다.

여러 인코딩은 별도의 HTTP Accept-Encoding 헤더로 지정하거나, 쉼표로 구분된 목록으로 지정합니다. 선호도나 우선순위를 나타내기 위해 q 계수도 함께 포함됩니다.

SEO 영향

Google의 크롤러와 페처는 gzip, deflate, Brotli(br) 콘텐츠 인코딩을 지원합니다. 각 Google 사용자 에이전트는 모든 요청의 Accept-Encoding 헤더에 지원 인코딩을 알리며, 보통 Accept-Encoding: gzip, deflate, br 형태입니다. Googlebot에 압축된 응답을 제공하면 대역폭과 크롤 시간이 줄어듭니다. Bingbot은 Accept-Encoding: gzip, deflate를 보냅니다.

gzip

gzip 디렉티브는 클라이언트가 GNU zip 압축을 지원함을 나타냅니다. 웹에서 가장 널리 지원되는 인코딩입니다.

deflate

deflate 디렉티브는 클라이언트가 zlib 압축을 지원함을 나타냅니다. 이름과 달리 원시 DEFLATE 압축 데이터를 zlib으로 감싼 형태를 사용합니다.

br

br 디렉티브는 클라이언트가 Brotli 압축을 지원함을 나타냅니다. Brotli는 텍스트 기반 콘텐츠에서 보통 gzip보다 더 나은 압축률을 냅니다.

zstd

zstd 디렉티브는 클라이언트가 Zstandard 압축을 지원함을 나타냅니다. Zstandard는 높은 압축률과 빠른 압축 해제 속도를 함께 제공합니다.

identity

identity 디렉티브는 어떤 인코딩도 적용하지 않음을 나타냅니다. 이 값은 identity;q=0으로 명시적으로 배제하지 않는 한 언제나 받아들일 수 있는 것으로 간주됩니다.

* (와일드카드)

  • 와일드카드는 헤더에 아직 나열되지 않은 모든 인코딩에 일치합니다. Accept-Encoding 헤더가 없으면 서버는 요청에 *가 지정된 것처럼 취급합니다.

;q= (품질 값)

;q= 매개변수는 각 인코딩에 0과 1 사이의 가중치를 부여하며, 1이 가장 높은 우선순위이고 0은 “받아들일 수 없음”을 뜻합니다. 생략하면 기본 품질 값은 1입니다. 서버는 이 가중치를 사용해 선호하는 인코딩을 선택합니다.

예시

이 예시에서 클라이언트는 여러 인코딩 방식 중 하나를 사용하도록 서버에 요청합니다. 첫 번째 변형에서는 각 선택지에 동등한 우선순위가 부여됩니다. 두 번째 변형에서는 q 값 디렉티브를 사용해 인코딩 우선순위에 가중치를 부여합니다. 서버는 적용된 인코딩 목록을 처리 순서대로 담아 응답합니다.

요청 (변형 #1)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

요청 (변형 #2)

GET / HTTP/1.1
Host: example.com
Accept-Encoding: gzip, deflate, br;q=1.0, identity;q=0.5, *;q=0.25

응답

HTTP/1.1 200 OK
Content-Encoding: gzip, br

문제 해결

Accept-Encoding을 보냈는데도 압축이 적용되지 않습니다. 일부 리버스 프록시는 요청을 전달하기 전에 Accept-Encoding을 제거합니다. nginx에서는 proxy_set_header Accept-Encoding $http_accept_encoding 으로 원래 값을 보존할 수 있습니다. curl -H “Accept-Encoding: gzip” -I 로 확인하십시오.

예상과 다른 인코딩이 선택됩니다. 품질 값(q 계수)이 선호 순서를 정합니다. Accept-Encoding: gzip;q=0.5, br;q=1.0 인 요청은 Brotli를 선호합니다. q 값을 생략하면 동등한 가중치가 부여되어 서버가 자유롭게 선택합니다.

CORS 사전 요청에 Accept-Encoding이 없습니다. Accept-Encoding 헤더는 CORS 안전 목록에 있어 사전 요청을 유발하지 않습니다. 교차 출처 요청에서 압축이 작동하지 않는다면, 서버가 Origin 헤더와 무관하게 압축을 적용하는지 확인하십시오.

CDN이 압축되지 않은 응답을 제공합니다. 일부 CDN은 오리진이 적절한 Content-Type과 함께 압축되지 않은 응답을 보낼 때만 압축합니다. CDN이 압축본과 비압축본을 각각 캐시하도록 오리진이 Vary: Accept-Encoding으로 응답하는지 확인하십시오.

identity 인코딩이 거부됩니다. Accept-Encoding: identity;q=0 을 보내면 클라이언트가 압축되지 않은 응답을 받아들일 수 없다고 서버에 알리는 것입니다. 지원되는 인코딩이 하나도 없으면 서버는 406 Not Acceptable을 반환합니다. 나열된 모든 인코딩을 반드시 사용할 수 있다고 보장되지 않는 한 identity를 q=0으로 설정하지 마십시오.