| 인터넷 엔지니어링 태스크 포스 (IETF) | M. Nottingham |
| Request for Comments: 9209 | Fastly |
| 카테고리: 표준 트랙 | P. Sikora |
| ISSN: 2070-1721 | |
| 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. 소개
- 2. Proxy-Status HTTP
필드
- 2.1. Proxy-Status 매개변수
- 2.2. 새 Proxy-Status 매개변수 정의
- 2.3. 프록시
오류 유형
- 2.3.1. DNS 시간 초과
- 2.3.2. DNS 오류
- 2.3.3. 대상 없음
- 2.3.4. 대상 사용 불가
- 2.3.5. 대상 IP 금지
- 2.3.6. 대상 IP 경로 없음
- 2.3.7. 연결 거부됨
- 2.3.8. 연결 종료됨
- 2.3.9. 연결 시간 초과
- 2.3.10. 연결 읽기 시간 초과
- 2.3.11. 연결 쓰기 시간 초과
- 2.3.12. 연결 한도 초과
- 2.3.13. TLS 프로토콜 오류
- 2.3.14. TLS 인증서 오류
- 2.3.15. TLS 경고 수신
- 2.3.16. HTTP 요청 오류
- 2.3.17. HTTP 요청 거부
- 2.3.18. HTTP 불완전 응답
- 2.3.19. HTTP 응답 헤더 섹션 너무 큼
- 2.3.20. HTTP 응답 헤더 필드 라인 너무 김
- 2.3.21. HTTP 응답 본문 너무 큼
- 2.3.22. HTTP 응답 트레일러 섹션 너무 큼
- 2.3.23. HTTP 응답 트레일러 필드 라인 너무 김
- 2.3.24. HTTP 응답 전송 인코딩 오류
- 2.3.25. HTTP 응답 콘텐츠 인코딩 오류
- 2.3.26. HTTP 응답 시간 초과
- 2.3.27. HTTP 업그레이드 실패
- 2.3.28. HTTP 프로토콜 오류
- 2.3.29. 프록시 내부 응답
- 2.3.30. 프록시 내부 오류
- 2.3.31. 프록시 구성 오류
- 2.3.32. 프록시 루프 감지
- 2.4. 새 프록시 오류 유형 정의
- 3. IANA 고려사항
- 4. 보안 고려사항
- 5. 참조
- 저자 주소
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"은 요청에 대해 원본 서버로 가는 방향의 연결을 나타냅니다.
2. Proxy-Status HTTP 필드
Proxy-Status HTTP 응답 필드는 중개자가 응답 및 관련 요청의 처리에 대해 추가 정보를 전달할 수 있게 합니다.
그 값은 List입니다(자세한 내용은 Section 3.1의 [STRUCTURED-FIELDS]). 리스트의 각 항목은 응답을 처리한 중개자를 나타냅니다. 첫 번째 항목은 원본 서버에 가장 가까운 중개자를 나타내고, 마지막 항목은 사용자 에이전트에 가장 가까운 중개자를 나타냅니다.
예를 들면:
Proxy-Status: revproxy1.example.net, ExampleCDN
이는 이 응답이 먼저 revproxy1.example.net(원본 서버에 인접한 리버스 프록시)에 의해 처리된 다음 ExampleCDN에 의해 처리되었음을 나타냅니다.
중개자는 언제 Proxy-Status 필드를 응답에 추가할지 스스로 판단합니다. 일부는 모든 응답에 덧붙일 수 있고, 다른 일부는 명시적으로 구성되었거나 요청에 디버깅 모드를 활성화하는 헤더 필드가 포함된 경우에만 추가할 수 있습니다.
리스트의 각 멤버는 해당 값을 삽입한 중개자를 식별하며 String 또는 Token 형식이어야 합니다. 배포 환경에 따라 서비스 명(배포를 식별하는 이름이 되어야 함; 예: "ExampleCDN"은 적절하지만 제품명인 "ExampleProxy"는 적절치 않음), 호스트명("proxy-3.example.com"), IP 주소 또는 생성된 문자열일 수 있습니다.
각 멤버의 매개변수(참조: Section 3.1.2의 [STRUCTURED-FIELDS])는 해당 중개자의 응답 및 관련 요청 처리에 대한 추가 정보를 전달합니다; 자세한 내용은 섹션 2.1을 참조하십시오. 이들 매개변수는 모두 선택 사항이지만(OPTIONAL) 중개자는 가능한 한 많은 정보를 제공하는 것이 권장됩니다(다만 그렇게 할 때의 보안 고려사항은 섹션 4 참조).
값을 Proxy-Status 필드에 추가할 때 중개자는 전체 중개자 체인의 디버깅을 허용하기 위해 필드의 기존 멤버를 보존해야 합니다(SHOULD), 단 내부 네트워크 세부정보 유출 방지 등으로 인해 명시적으로 제거하도록 구성된 경우는 예외입니다(자세한 내용은 섹션 4 참조).
원본 서버는 Proxy-Status 필드를 생성해서는 안 됩니다(MUST NOT).
Proxy-Status 필드는 HTTP 트레일러 필드로 전송될 수 있습니다(MAY). 예를 들어 중개자가 응답을 스트리밍하는 동안 인바운드 연결이 갑자기 종료되면 헤더 섹션을 이미 보냈기 때문에 Proxy-Status는 아웃바운드 메시지의 트레일러 섹션에만 추가될 수 있습니다. 다만 트레일러 필드는 경로상에서 조용히 폐기될 수 있으므로(모든 트레일러 필드와 마찬가지로; 자세한 내용은 Section 6.5의 [HTTP]) Proxy-Status는 헤더 섹션에 전송할 수 없는 경우가 아닌 한 트레일러로 보내서는 안 됩니다(SHOULD NOT).
트레일러 필드로 전달된 Proxy-Status 멤버와 헤더 필드로 전달된 멤버의 상대적 순서를 수신자가 재구성할 수 있도록 하려면, 중개자는 같은 메시지에서 동일한 멤버(매개변수는 다를 수 있음)를 가진 Proxy-Status 헤더 필드를 생성하지 않은 경우 트레일러로 Proxy-Status를 보내면 안 됩니다(MUST NOT).
예를 들어 'ThisProxy'로 식별되는 프록시가 다음과 같은 헤더 필드를 가진 응답을 받으면:
Proxy-Status: SomeOtherProxy
다음과 같이 자신의 항목을 헤더 필드에 추가합니다:
Proxy-Status: SomeOtherProxy, ThisProxy
이렇게 하면 트레일러 필드를 추가할 수 있습니다:
Proxy-Status: ThisProxy; error=read_timeout
이로써 하류 수신자는 'SomeOtherProxy'가 'ThisProxy'보다 먼저 처리했음을 이해할 수 있습니다.
클라이언트는 다음 절차를 따라 Proxy-Status 트레일러 필드를 헤더 필드로 승격할 수 있습니다(MAY):
-
Proxy-Status 트레일러 필드 값의 각 멤버 trailer_member에 대해:
- Proxy-Status 헤더 필드 값의 첫 번째(왼쪽) 값을 header_member라고 하되, 매개변수는 고려하지 않고 String 또는 Token을 문자 단위로 비교합니다.
- 일치하는 header_member가 없으면 다음 trailer_member로 계속합니다.
- header_member를 해당 trailer_member 전체로 교체하되 매개변수까지 포함합니다.
- Proxy-Status 트레일러 필드가 비어 있으면 제거합니다.
2.1. Proxy-Status 매개변수
이 섹션은 Proxy-Status 필드의 멤버에 사용할 수 있는 매개변수를 나열합니다. 인식되지 않는 매개변수는 무시되어야 합니다(MUST).
2.1.1. error
error 매개변수의 값은 프록시 오류 유형을 나타내는 Token입니다. 존재할 경우 중개자가 이 응답을 얻는 동안 문제를 만났음을 나타냅니다.
일부 프록시 오류 유형의 존재는 응답이 원본 서버에서 전달된 것이 아니라 중개자 자체에 의해 생성되었음을 나타냅니다. 예를 들어 원본 서버에 접속할 수 없어 프록시가 자체적으로 응답을 생성해야 하는 경우가 이에 해당합니다.
다른 프록시 오류 유형은 원본 서버나 다른 인바운드 서버가 생성한(부분적일 수 있는) 응답에 추가될 수 있습니다. 예를 들어 포워드 연결이 갑자기 닫힌 경우 중개자는 트레일러 필드로 적절한 오류를 포함한 Proxy-Status를 추가할 수 있습니다.
'Response only generated by intermediaries' 값이 'true'로 등록된 프록시 오류 유형은 중개자에 의해 생성된 응답에서만 발생할 수 있음을 나타냅니다. 값이 'false'이면 응답이 중개자 또는 인바운드 서버에 의해 생성될 수 있습니다.
예:
HTTP/1.1 504 Gateway Timeout Proxy-Status: ExampleCDN; error=connection_timeout
이는 이 504 응답이 포워드 시 연결 시간 초과로 인해 ExampleCDN에 의해 생성되었음을 나타냅니다.
또는:
HTTP/1.1 429 Too Many Requests Proxy-Status: r34.example.net; error=http_request_error, ExampleCDN
이는 이 429 응답이 CDN이나 원본이 아니라 r34.example.net에 의해 생성되었음을 나타냅니다.
error 매개변수를 보낼 때는 오류 상태를 정확히 나타낼 수 있다면 가장 구체적인 프록시 오류 유형을 보내는 것이 권장됩니다(SHOULD). 적절한 유형이 정의되어 있지 않으면 proxy_internal_error, http_protocol_error 같은 일반적인 오류 유형을 사용할 수 있습니다. 이들도 적합하지 않으면 새로운 프록시 오류 유형을 등록하는 것을 고려하세요(섹션 2.4 참조).
각 프록시 오류 유형에는 권장 HTTP 상태 코드가 있습니다. error를 포함하는 HTTP 응답을 생성할 때 그 HTTP 상태 코드는 권장 코드로 설정하는 것이 바람직합니다(SHOULD). 다만 이전 동작과의 호환성 등으로 이미 상태 코드가 전송된 경우 다른 상태 코드를 사용할 수 있습니다.
프록시 오류 유형은 그 유형과 함께 사용할 수 있는 임의의 추가 매개변수를 정의할 수 있습니다. 이들의 사용은 선택 사항이며, 따라서 특정 프록시 오류 유형에 대해 정의되지 않은 추가 매개변수가 사용되면 무시됩니다.
2.1.2. next-hop
next-hop 매개변수의 값은 이 응답을 얻기 위해 선택(및 접촉된 경우 사용)된 중개자 또는 원본 서버를 식별하는 String 또는 Token입니다. 호스트명, IP 주소 또는 별칭일 수 있습니다.
예:
Proxy-Status: cdn.example.org; next-hop=backend.example.org:8001
이는 cdn.example.org가 이 요청의 next hop으로 backend.example.org:8001을 사용했음을 나타냅니다.
2.1.3. next-protocol
next-protocol 매개변수의 값은 중개자가 이 응답을 얻기 위해 next hop에 연결할 때 사용한 Application-Layer Protocol Negotiation (ALPN) 프로토콜 식별자를 나타냅니다(참조: [RFC7301]).
값은 TLS ALPN Protocol ID를 나타내는 Token 또는 Byte Sequence여야 하며(MUST). 프로토콜 식별자가 ASCII 인코딩으로 Token으로 표현될 수 있다면 그 형태를 사용해야 합니다(MUST).
예:
Proxy-Status: "proxy.example.org"; next-protocol=h2
여기서는 ALPN 식별자가 사용 중인 프로토콜을 식별하는 데 사용됨을 주의하세요; 실제로 프로토콜 협상에서 사용되었는지 여부와는 무관할 수 있습니다.
2.1.4. received-status
received-status 매개변수의 값은 중개자가 이 응답을 얻을 때 next-hop 서버로부터 수신한 HTTP 상태 코드를 나타냅니다.
값은 정수여야 합니다(MUST).
예:
Proxy-Status: ExampleCDN; received-status=200
2.1.5. details
details 매개변수의 값은 다른 곳에 캡처되지 않은 추가 정보를 포함하는 String입니다. 구현별 또는 배포별 정보가 포함될 수 있습니다.
예:
Proxy-Status: proxy.example.net; error="http_protocol_error";
details="Malformed response header: space before colon"
2.2. 새 Proxy-Status 매개변수 정의
새 Proxy-Status 매개변수는 "HTTP Proxy-Status Parameters" 레지스트리에 등록하여 정의할 수 있습니다.
등록 요청은 전문가 검토(Expert Review)에 의해 검토되고 승인됩니다(참조: RFC8126, Section 4.5). 명세 문서는 권장되지만 필수는 아닙니다.
전문가는 요청을 평가할 때 다음 요소를 고려해야 합니다:
- 커뮤니티 피드백
- 값이 충분히 정의되었는지 여부
- 일반적인 매개변수가 공급업체별, 애플리케이션별 또는 배포별 값보다 선호됩니다. 커뮤니티에서 일반 값을 합의할 수 없다면 매개변수 이름은 공급업체, 애플리케이션 또는 배포를 식별하는 접두사를 포함하는 등 그에 맞게 구체적이어야 합니다.
- 매개변수 이름은 "HTTP Proxy Error Types" 레지스트리에 등록된 추가 매개변수와 충돌하지 않아야 합니다.
등록 요청은 다음 템플릿을 사용해야 합니다:
- Name:
- [Proxy-Status 매개변수의 key에 맞는 이름]
- Description:
- [매개변수 의미와 값에 대한 설명]
- Reference:
- [이 매개변수를 정의하는 명세에 대한 참조; 선택사항]
등록 요청을 보낼 위치에 대한 자세한 내용은 <https://www.iana.org/assignments/http-proxy-status>의 레지스트리를 참조하십시오.
2.3. 프록시 오류 유형
이 섹션은 이 문서에서 정의한 프록시 오류 유형을 나열합니다. 새로운 프록시 오류 유형 정의에 대한 정보는 섹션 2.4을 참조하세요.
구현체가 모든 프록시 오류 유형을 생성하지 않을 수 있다는 점에 유의하세요. 아래 유형 집합은 구현의 기존 상태에 매핑되도록 설계되었으므로 일부 구현에는 적용되지 않을 수 있습니다.
2.3.1. DNS 시간 초과
- Name:
- dns_timeout
- Description:
- 중개자가 next-hop 호스트 이름의 IP 주소를 찾는 동안 타임아웃이 발생했습니다.
- Extra Parameters:
- 없음
- Recommended HTTP Status Code:
- 504
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.2. DNS 오류
- Name:
- dns_error
- Description:
- 중개자가 next-hop 호스트 이름의 IP 주소를 찾는 동안 DNS 오류를 만났습니다.
- Extra Parameters:
-
- Recommended HTTP Status Code:
- 502
- Response Only Generated by Intermediaries:
- true
- Reference:
- RFC 9209
2.3.3. 대상 찾을 수 없음
- 이름:
- destination_not_found
- 설명:
- 중개자가 이 요청에 사용할 적절한 다음 홉(next hop)을 결정할 수 없습니다. 예를 들어 구성되지 않았을 수 있습니다. 이 오류는 일반적으로 백엔드 서버를 식별하기 위한 특정 구성이 필요한 게이트웨이에 특화된 오류임에 유의하십시오; 포워드 프록시는 오리진 서버를 식별하기 위해 인밴드 정보를 사용합니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 500
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.5. 대상 IP 금지
- 이름:
- destination_ip_prohibited
- 설명:
- 중개자가 다음 홉의 IP 주소로의 연결을 금지하도록 구성되어 있습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.6. 대상 IP 경로 없음
- 이름:
- destination_ip_unroutable
- 설명:
- 중개자가 다음 홉 IP 주소로 가는 경로를 찾을 수 없습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.7. 연결 거부됨
- 이름:
- connection_refused
- 설명:
- 중개자가 다음 홉으로의 연결을 시도했지만 거부되었습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.8. 연결 종료됨
- 이름:
- connection_terminated
- 설명:
- 중개자가 다음 홉과의 연결을 닫았으며, 완전한 응답을 받기 전에 종료되었습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.9. 연결 시간 초과
- 이름:
- connection_timeout
- 설명:
- 중개자가 다음 홉으로의 연결을 열려고 시도했으나 시간 초과가 발생했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 504
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.10. 연결 읽기 시간 초과
- 이름:
- connection_read_timeout
- 설명:
- 중개자가 연결(예: 응답의 일부)에서 데이터를 기대하고 있었으나 구성된 시간 내에 새로운 데이터를 받지 못했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 504
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.11. 연결 쓰기 시간 초과
- 이름:
- connection_write_timeout
- 설명:
- 중개자가 연결에 데이터를 쓰려고 시도했으나 (예: 버퍼가 가득 참) 쓸 수 없었습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 504
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.12. 연결 한도 초과
- 이름:
- connection_limit_reached
- 설명:
- 중개자가 다음 홉으로의 연결 수를 제한하도록 구성되어 있으며, 그 한도가 초과되었습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 503
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.13. TLS 프로토콜 오류
- 이름:
- tls_protocol_error
- 설명:
- 중개자가 다음 홉과 통신할 때 핸드셰이크 중이거나 이후에 TLS 오류를 만났습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
- 주석:
- TLS 경고를 수신했을 때는 적절하지 않습니다; tls_alert_received를 참조하세요.
2.3.14. TLS 인증서 오류
- 이름:
- tls_certificate_error
- 설명:
- 중개자가 다음 홉이 제시한 인증서를 검증하는 동안 오류를 만났습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.15. TLS 경고 수신
2.3.16. HTTP 요청 오류
- 이름:
- http_request_error
- 설명:
- 중개자가 오리진을 대신하여 클라이언트(4xx) 응답을 생성하고 있습니다. 적용 가능한 상태 코드는 400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, 429 등을 포함하되 이에 국한되지 않습니다.
- 추가 매개변수:
-
- status-code:
- 생성된 상태 코드를 포함하는 Integer입니다.
- status-phrase:
- 생성된 상태 구문(status phrase)을 포함하는 String입니다.
- 권장 HTTP 상태 코드:
- 해당되는 4xx 상태 코드
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
- 주석:
- 이 유형은 중개자가 생성한 응답과 오리진이 생성한 응답을 구별하는 데 도움이 됩니다.
2.3.17. HTTP 요청 거부
- 이름:
- http_request_denied
- 설명:
- 중개자가 구성 및/또는 정책 설정에 따라 HTTP 요청을 거부했습니다. 요청은 다음 홉으로 전달되지 않았습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 403
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.18. HTTP 불완전 응답
- 이름:
- http_response_incomplete
- 설명:
- 중개자가 다음 홉으로부터 요청에 대한 불완전한 응답을 수신했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.19. HTTP 응답 헤더 섹션 너무 큼
- 이름:
- http_response_header_section_size
- 설명:
- 중개자가 수신한 응답의 헤더 섹션이 너무 크다고 판단되었습니다.
- 추가 매개변수:
-
- header-section-size:
- 수신된 헤더의 크기를 나타내는 Integer입니다. 헤더가 완전하지 않을 수도 있다는 점에 유의하세요; 즉 중개자가 추가 데이터를 폐기하거나 거부했을 수 있습니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.20. HTTP 응답 헤더 필드 라인 너무 큼
- 이름:
- http_response_header_size
- 설명:
- 중개자가 수신한 응답에 포함된 개별 헤더 필드 라인이 너무 크다고 판단되었습니다.
- 추가 매개변수:
-
- header-name:
- 오류를 유발한 헤더 필드의 이름을 나타내는 String입니다.
- header-size:
- 오류를 유발한 헤더 필드의 크기를 나타내는 Integer입니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.21. HTTP 응답 본문 너무 큼
- 이름:
- http_response_body_size
- 설명:
- 중개자가 수신한 응답의 본문이 너무 크다고 판단되었습니다.
- 추가 매개변수:
-
- body-size:
- 수신된 본문의 크기를 나타내는 Integer입니다. 본문이 완전하지 않을 수 있다는 점에 유의하세요; 즉 중개자가 추가 데이터를 폐기하거나 거부했을 수 있습니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.22. HTTP 응답 트레일러 섹션 너무 큼
- 이름:
- http_response_trailer_section_size
- 설명:
- 중개자가 수신한 응답의 트레일러 섹션이 너무 크다고 판단되었습니다.
- 추가 매개변수:
-
- trailer-section-size:
- 수신된 트레일러의 크기를 나타내는 Integer입니다. 트레일러가 완전하지 않을 수 있다는 점에 유의하세요; 즉 중개자가 추가 데이터를 폐기하거나 거부했을 수 있습니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.23. HTTP 응답 트레일러 필드 라인 너무 큼
- 이름:
- http_response_trailer_size
- 설명:
- 중개자가 수신한 응답에 포함된 개별 트레일러 필드 라인이 너무 크다고 판단되었습니다.
- 추가 매개변수:
-
- trailer-name:
- 오류를 유발한 트레일러 필드의 이름을 나타내는 String입니다.
- trailer-size:
- 오류를 유발한 트레일러 필드의 크기를 나타내는 Integer입니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.24. HTTP 응답 전송 인코딩 오류
- 이름:
- http_response_transfer_coding
- 설명:
- 중개자가 응답의 전송 인코딩(transfer coding)을 디코딩하는 중에 오류를 만났습니다.
- 추가 매개변수:
-
- coding:
- 오류를 발생시킨 특정 인코딩(“HTTP Transfer Coding Registry”의 값)을 포함하는 Token입니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.25. HTTP 응답 콘텐츠 인코딩 오류
- 이름:
- http_response_content_coding
- 설명:
- 중개자가 응답의 콘텐츠 인코딩(content coding)을 디코딩하는 중에 오류를 만났습니다.
- 추가 매개변수:
-
- coding:
- 오류를 발생시킨 특정 인코딩(“HTTP Content Coding Registry”의 값)을 포함하는 Token입니다.
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.26. HTTP 응답 시간 초과
- 이름:
- http_response_timeout
- 설명:
- 중개자가 완전한 응답을 기다리는 동안 구성된 시간 한도에 도달했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 504
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.27. HTTP 업그레이드 실패
- 이름:
- http_upgrade_failed
- 설명:
- 중개자와 다음 홉 간의 HTTP 버전 업그레이드 협상이 실패했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.28. HTTP 프로토콜 오류
- 이름:
- http_protocol_error
- 설명:
- 중개자가 다음 홉과 통신할 때 HTTP 프로토콜 오류를 만났습니다. 더 구체적인 오류가 정의되어 있지 않을 때에만 이 오류를 사용해야 합니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- false
- 참조:
- RFC 9209
2.3.29. 프록시 내부 응답
- 이름:
- proxy_internal_response
- 설명:
- 중개자가 다음 홉에 연결하려 시도하지 않고 스스로 응답을 생성했습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 응답에 적합한 가장 적절한 상태 코드
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.30. 프록시 내부 오류
- 이름:
- proxy_internal_error
- 설명:
- 중개자가 오리진과 관련 없는 내부 오류를 만났습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 500
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.31. 프록시 구성 오류
- 이름:
- proxy_configuration_error
- 설명:
- 중개자가 구성과 관련된 오류를 만났습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 500
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.3.32. 프록시 루프 감지
- 이름:
- proxy_loop_detected
- 설명:
- 중개자가 요청을 자기 자신으로 전달하려 했거나, 다른 방식(예: RFC8586)으로 루프가 감지되었습니다.
- 추가 매개변수:
- 없음
- 권장 HTTP 상태 코드:
- 502
- 중개자만 생성하는 응답:
- true
- 참조:
- RFC 9209
2.4. 새 프록시 오류 유형 정의
새로운 프록시 오류 유형은 "HTTP Proxy Error Types" 레지스트리에 등록하여 정의할 수 있습니다.
등록 요청은 전문가 검토(Expert Review)에 의해 검토되고 승인됩니다(참조: RFC8126, Section 4.5). 명세 문서는 권장되지만 필수는 아닙니다.
전문가는 요청을 평가할 때 다음 요소를 고려해야 합니다:
- 커뮤니티 피드백
- 값이 충분히 정의되었는지 여부
- 일반적인 유형이 공급업체별, 애플리케이션별 또는 배포별 값보다 선호됩니다. 일반적인 값에 합의할 수 없다면, 유형 이름은 공급업체·애플리케이션·배포를 식별하는 접두사를 포함하는 등 그에 맞게 구체적이어야 합니다.
- 추가 매개변수는 등록된 Proxy-Status 매개변수와 충돌하지 않아야 합니다.
등록 요청은 다음 템플릿을 사용해야 합니다:
- 이름:
- [Token 타입인 프록시 오류 유형 이름]
- 설명:
- [프록시 오류 유형을 생성하는 조건에 대한 설명]
- 추가 매개변수:
- [0개 이상의 선택적 매개변수 및 허용되는 Structured Type(s)]
- 권장 HTTP 상태 코드:
- [이 항목에 적합한 HTTP 상태 코드]
- 중개자만 생성하는 응답:
- ['true' 또는 'false']
- 참조:
- [이 오류 유형을 정의하는 명세에 대한 참조; 선택사항]
- 주석:
- [선택사항]
프록시 오류 유형이 중개자가 생성하지 않은 응답에서도 발생할 수 있는 경우(예: 포워드 연결에서 스트리밍되는 응답을 처리하던 중 오류가 감지되어 Proxy-Status 트레일러 필드가 추가되는 경우) '중개자만 생성하는 응답'은 'false'여야 합니다. 오류 유형이 중개자가 생성한 응답에서만 발생한다면 'true'여야 합니다.
등록 요청을 보낼 위치에 대한 자세한 내용은 <https://www.iana.org/assignments/http-proxy-status>의 레지스트리를 참조하세요.
3. IANA 고려사항
IANA는 "HTTP Proxy-Status Parameters" 레지스트리와 "HTTP Proxy Error Types" 레지스트리를 생성하고, <https://www.iana.org/assignments/http-proxy-status>에서 관리하며, 섹션 2.1 및 2.3에 정의된 유형들로 채웠습니다. 관련 절차는 2.2 및 2.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>.