인터넷 엔지니어링 태스크 포스 (IETF) M. Nottingham
Request for Comments: 9209 Fastly
카테고리: 표준 트랙 P. Sikora
ISSN: 2070-1721 Google
2022년 6월

Proxy-Status HTTP 응답 헤더 필드


요약

이 문서는 중개자(intermediary)의 응답 처리 세부정보(생성된 오류 포함)를 전달하기 위한 Proxy-Status HTTP 응답 필드를 정의합니다.

이 메모의 상태

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

이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산물입니다. 이 문서는 IETF 커뮤니티의 합의를 나타냅니다. 공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)의 출판 승인을 받았습니다. 인터넷 표준에 대한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.

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

Copyright Notice

Copyright (c) 2022 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 (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. 소개

HTTP 중개자들(자세한 내용은 Section 3.7[HTTP]) — 포워드 프록시와 게이트웨이(일반적으로 "리버스 프록시"로 알려짐)를 포함 — 는 HTTP 배포에서 점점 더 중요한 부분이 되었습니다. 특히 리버스 프록시와 CDN(콘텐츠 전송 네트워크)은 많은 웹사이트의 중요한 인프라를 구성합니다.

일반적으로 HTTP 중개자는 원본 서버 쪽으로 요청을 전달하고(인바운드) 그 응답을 클라이언트로 다시 전달합니다(아웃바운드). 그러나 인바운드 서버로부터 응답을 얻기 전에 오류가 발생하면, 응답은 종종 중개자 자체에 의해 생성됩니다.

HTTP는 이러한 유형의 오류를 몇 가지 상태 코드(예: 502 Bad Gateway, 504 Gateway Timeout)로 수용합니다. 그러나 경험적으로 디버깅을 돕고 클라이언트에게 발생한 일을 전달하려면 더 많은 정보가 필요하다는 것이 드러났습니다. 또한 중개자는 응답을 생성하지 않았더라도 자신의 응답 처리에 대한 추가 정보를 전달하려는 경우가 있습니다.

이러한 사용을 가능하게 하기 위해 섹션 2는 중개자가 응답 처리에 대한 세부사항을 전달할 수 있도록 하는 새로운 HTTP 응답 필드를 정의합니다. 섹션 2.1은 중개자가 필드에 추가할 수 있는 정보를 열거하며, 이는 섹션 2.2에 따라 확장될 수 있습니다. 섹션 2.3은 요청에 대한 응답을 얻을 때 프록시가 문제를 만났을 때 사용할 오류 유형 집합을 정의하며, 이는 섹션 2.4에 따라 확장될 수 있습니다.

1.1. 표기 규약

이 문서에서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 모두 대문자로 사용될 때에 한해 BCP 14(RFC2119) 및 RFC8174에 설명된 대로 해석됩니다.

이 문서는 구문 및 파싱을 지정하기 위해 Section 3의 용어(List, String, Token, Integer, Byte Sequence)를 사용합니다(참조: [STRUCTURED-FIELDS]).

이 명세에서 "proxy"는 포워드 및 리버스 프록시(게이트웨이)를 모두 가리키는 데 사용됩니다. "Next hop"은 요청에 대해 원본 서버로 가는 방향의 연결을 나타냅니다.



3. IANA 고려사항

IANA는 "HTTP Proxy-Status Parameters" 레지스트리와 "HTTP Proxy Error Types" 레지스트리를 생성하고, <https://www.iana.org/assignments/http-proxy-status>에서 관리하며, 섹션 2.12.3에 정의된 유형들로 채웠습니다. 관련 절차는 2.22.4를 참조하세요.

또한 다음 항목이 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 추가되었습니다:

필드 이름:
Proxy-Status
상태:
permanent
명세 문서:
RFC 9209
코멘트:
 

4. 보안 고려사항

Proxy-Status 사용 시 주요 보안 우려사항 중 하나는 공격자에게 도움이 될 수 있는 정보를 유출하는 것입니다. 예를 들어 중개자의 구성 및 백엔드 토폴로지 정보가 노출되면 공격자가 트래픽이 많거나 잘못된 입력에 대비하지 못한 백엔드 서비스를 직접 공격할 수 있습니다. 일부 정보는 권한이 있는 당사자에게만 공개되어야 할 수 있습니다.

따라서 Proxy-Status 필드를 생성할지 및 어떤 정보를 포함할지 결정할 때 주의가 필요합니다. 중개자는 어느 응답에도 Proxy-Status 필드를 생성할 의무가 없으며 요청 속성(예: 인증 토큰, IP 주소)에 따라 조건부로 생성할 수 있다는 점을 유의하세요.

마찬가지로 모든 매개변수의 생성은 선택사항이며, 필드 자체의 생성도 선택사항입니다. 또한 필드의 내용은 검증되지 않으므로 중개자가 암호화 채널을 통해 요청을 보냈다고 주장했더라도 실제로 그렇게 하지 못했을 수 있습니다.

5. 참조

5.1. 규범 참조

[HTTP]
Fielding, R., Nottingham, M., 및 J. Reschke, 편집, “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, 2022년 6월, <https://www.rfc-editor.org/info/rfc9110>.
[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997년 3월, <https://www.rfc-editor.org/info/rfc2119>.
[RFC7301]
Friedl, S., Popov, A., Langley, A., 및 E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, 2014년 7월, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8126]
Cotton, M., Leiba, B., 및 T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, 2017년 6월, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499]
Hoffman, P., Sullivan, A., 및 K. Fujiwara, “DNS Terminology”, BCP 219, RFC 8499, DOI 10.17487/RFC8499, 2019년 1월, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8914]
Kumari, W., Hunt, E., Arends, R., Hardaker, W., 및 D. Lawrence, “Extended DNS Errors”, RFC 8914, DOI 10.17487/RFC8914, 2020년 10월, <https://www.rfc-editor.org/info/rfc8914>.
[STRUCTURED-FIELDS]
Nottingham, M. 및 P-H. Kamp, “Structured Field Values for HTTP”, RFC 8941, DOI 10.17487/RFC8941, 2021년 3월, <https://www.rfc-editor.org/info/rfc8941>.
[TLS]
Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, 2018년 8월, <https://www.rfc-editor.org/info/rfc8446>.

5.2. 정보 참조

[RFC8586]
Ludin, S., Nottingham, M., 및 N. Sullivan, “Loop Detection in Content Delivery Networks (CDNs)”, RFC 8586, DOI 10.17487/RFC8586, 2019년 4월, <https://www.rfc-editor.org/info/rfc8586>.

저자 주소

Mark Nottingham
Fastly
Prahran
Australia
EMail: mnot@mnot.net
URI: https://www.mnot.net/
Piotr Sikora
Google
EMail: piotrsikora@google.com