| 인터넷 엔지니어링 태스크 포스 (IETF) | J. Reschke |
| 의견 요청: 7694 | greenbytes |
| 카테고리: 표준 트랙 | 2015년 11월 |
| ISSN: 2070-1721 |
하이퍼텍스트 전송 프로토콜 (HTTP) 클라이언트 주도 콘텐츠 인코딩
요약
HTTP에서 콘텐츠 코딩은 압축이나 무결성 검사와 같은 페이로드 인코딩을 허용합니다. 특히 "gzip" 콘텐츠 코딩은 응답 메시지로 전송되는 페이로드 데이터에 널리 사용됩니다.
콘텐츠 코딩은 요청 메시지에서도 사용될 수 있지만, 응답 메시지만큼 쉽게 발견되지는 않습니다. 이 문서는 응답에서 사용하기 위해 HTTP "Accept-Encoding" 헤더 필드를 확장하여, 요청에서 지원되는 콘텐츠 코딩을 표시할 수 있도록 합니다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서입니다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 반영합니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 스티어링 그룹(IESG)에 의해 발행 승인을 받았습니다. 인터넷 표준에 관한 추가 정보는 RFC 5741의 섹션 2를 참조하십시오.
이 문서의 현재 상태, 정오표, 피드백 제공 방법에 관한 정보는 http://www.rfc-editor.org/info/rfc7694에서 확인할 수 있습니다.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. 소개
2. 표기 규약
이 문서에서 사용된 핵심 용어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 및 "OPTIONAL"은 [RFC2119]에 설명된 대로 해석됩니다.
3. 응답에서 'Accept-Encoding' 헤더 필드 사용
이 명세서는 그 정의를 확장하여 "Accept-Encoding"을 응답 헤더 필드로 허용합니다. 응답에 포함될 경우, 이는 해당 자원이 연관된 요청에서 수용하려고 했던 콘텐츠 코딩을 나타냅니다. 값이 "identity"만 포함하는 경우는 어떤 콘텐츠 코딩도 지원하지 않았음을 의미합니다.
이 정보는 연관된 요청에 특화된 것이며, 동일 서버의 다른 자원에 대해 지원되는 인코딩 집합은 다를 수 있고 시간에 따라 변경되거나 요청 방법과 같은 요청의 다른 측면에 따라 달라질 수 있습니다.
서버가 지원되지 않는 콘텐츠 코딩으로 인해 요청을 실패시키는 경우 415 상태로 응답하고, 클라이언트가 콘텐츠 코딩 문제와 미디어 타입 문제를 구별할 수 있도록 해당 응답에 "Accept-Encoding" 헤더 필드를 포함하는 것이 좋습니다. 반대로 콘텐츠 코딩과 무관한 이유로 415를 반환하는 경우, 혼동을 피하기 위해 MUST NOT "Accept-Encoding" 헤더 필드를 포함해서는 안 됩니다.
"Accept-Encoding"이 응답에서 가장 흔히 사용되는 경우는 클라이언트의 낙관적(optimistic) 요청에서 콘텐츠 코딩이 사용되어 실패했을 때 415 상태로 응답하는 경우일 것으로 예상됩니다. 그러나 이 헤더 필드는 또한 향후 상호작용을 최적화하기 위해 클라이언트에게 콘텐츠 코딩을 지원함을 알리는 데 사용할 수 있습니다. 예를 들어, 요청 페이로드가 압축 코딩 사용을 정당화할 만큼 충분히 컸지만 클라이언트가 압축하지 못한 경우, 자원은 2xx 응답에 이 헤더를 포함할 수 있습니다.
4. 예시
클라이언트가 "compress" 콘텐츠 코딩을 사용하여 POST 요청을 제출합니다 ([RFC7231], 섹션 3.1.2.1):
POST /edit/ HTTP/1.1 Host: example.org Content-Type: application/atom+xml;type=entry Content-Encoding: compress ...compressed payload...
서버는 해당 자원이 "gzip" 콘텐츠 코딩만 허용하므로 요청을 거부합니다:
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: gzip
Content-Length: 68
Content-Type: text/plain
This resource only supports the "gzip" content coding in requests.
이 시점에서 클라이언트는 지원되는 "gzip" 콘텐츠 코딩으로 요청을 재시도할 수 있습니다.
또는, 요청에서 어떤 콘텐츠 코딩도 지원하지 않는 서버는 다음과 같이 응답할 수 있습니다:
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: identity
Content-Length: 61
Content-Type: text/plain
This resource does not support content codings in requests.
5. 배포 고려사항
요청에서 콘텐츠 코딩을 지원하지 않는 서버는 이미 콘텐츠 코딩을 사용하는 요청을 실패시켜야 합니다. 섹션 6.5.13 of [RFC7231] 은 이 목적을 위한 상태 코드 415(Unsupported Media Type)를 정의하므로, 필요한 유일한 변경은 해당 응답에 값이 "identity"인 "Accept-Encoding" 헤더 필드를 포함하는 것입니다.
일부 콘텐츠 코딩을 지원하는 서버 역시 지원되지 않는 콘텐츠 코딩을 가진 요청을 실패시켜야 합니다. 이 명세를 준수하려면 서버는 문제를 알리기 위해 상태 코드 415(Unsupported Media Type)를 사용하고, 지원되는 콘텐츠 코딩을 나열하는 "Accept-Encoding" 헤더 필드를 포함해야 합니다. 지원되는 콘텐츠 코딩 집합은 보통 정적이고 작으므로, 헤더 필드를 추가하는 것은 간단해야 합니다.
6. 보안 고려사항
이 명세서는 지원되는 콘텐츠 코딩의 발견과 지원되지 않는 콘텐츠 코딩으로 인한 요청 실패에 대한 진단을 추가할 뿐이며, 따라서 HTTP/1.1 (섹션 9 of [RFC7231]) 및 HTTP/2 (섹션 10 of [RFC7540])에 이미 존재하는 보안 고려사항을 초과하는 새로운 보안 문제를 도입하지 않습니다.
그러나 더 나은 발견성과 진단의 목적은 요청에서 콘텐츠 코딩 사용을 더 쉽게 만드는 것입니다. 이는 gzip과 같은 압축 코딩의 사용 증가로 이어질 수 있으며 (섹션 4.2 of [RFC7230]), 보안 채널 위에서 사용될 때 BREACH와 같은 사이드 채널 공격을 가능하게 할 수 있습니다(자세한 내용은 RFC7540 섹션 10.6 및 [BREACH] 참조). 문서 출판 시점에는 BREACH 유사 공격이 요청 내 압축에 어떻게 적용될 수 있는지 불확실했습니다.
7. IANA 고려사항
7.1. 헤더 필드 레지스트리
HTTP 헤더 필드는 http://www.iana.org/assignments/message-headers에 위치한 "Message Headers" 레지스트리에 등록됩니다. 이 레지스트리는 [BCP90]에 정의되어 있습니다.
이 문서는 "Accept-Encoding" 헤더 필드의 정의를 갱신합니다. "Permanent Message Header Field Names" 레지스트리는 다음과 같이 갱신되었습니다:
7.2. 상태 코드 레지스트리
HTTP 상태 코드는 http://www.iana.org/assignments/http-status-codes에 위치한 "HTTP Status Codes" 레지스트리에 등록됩니다.
이 문서는 상태 코드 415(Unsupported Media Type)의 정의를 갱신합니다. "HTTP Status Codes" 레지스트리는 다음과 같이 갱신되었습니다:
8. 참고문헌
8.1. 규범적 참고문헌
- [RFC2119]
- Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
- [RFC7230]
- Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
- [RFC7231]
- Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
8.2. 비규범적 참고문헌
- [BCP90]
- Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.
- [BREACH]
- Gluck, Y., Harris, N., and A. Prado, “BREACH: Reviving the CRIME Attack”, July 2013, <http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
- [RFC7540]
- Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
감사의 글
Hypertext Transfer Protocol 작업 그룹 참가자들, 즉 Amos Jeffries, Ben Campbell, Mark Nottingham, Pete Resnick, Stephen Farrell, Ted Hardie에게 감사를 표합니다.