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

M. Nottingham

Request for Comments: 6585

Rackspace

Updates: 2616

R. Fielding

분류: 표준 트랙

Adobe

ISSN: 2070-1721

2012년 4월

추가 HTTP 상태 코드

초록

이 문서는 다양한 일반적인 상황에 대한 추가 HyperText Transfer Protocol(HTTP) 상태 코드를 명시합니다.

이 메모의 상태

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

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

이 문서의 현재 상태, 정오표(errata), 및 이에 대한 피드백 제공 방법에 관한 정보는 http://www.rfc-editor.org/info/rfc6585에서 얻을 수 있습니다.

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. 요구 사항
3. 428 사전 조건 필요
4. 429 요청이 너무 많음
5. 431 요청 헤더 필드가 너무 큼
6. 511 네트워크 인증 필요
7. 보안 고려사항
8. IANA 고려사항
9. 참조
Appendix A. 감사의 글
Appendix B. 캡티브 포털이 제기한 문제
저자 주소

1. 소개

이 문서는 다양한 일반적인 상황에 대해 상호 운용성을 개선하고 덜 명확한 상태 코드가 사용될 때의 혼동을 피하기 위해 추가적인 HTTP [RFC2616] 상태 코드를 명시합니다.

이들 상태 코드는 선택 사항임에 유의하십시오; 서버에 대해 이를 지원하도록 요구할 수는 없습니다. 다만, 클라이언트는 인식하지 못하는 상태 코드를 동일 클래스의 일반 오류로 취급(예: 499는 인식되지 않으면 400으로 처리)하므로 기존 서버에서도 안전하게 배포할 수 있습니다(자세한 내용은 [RFC2616] 섹션 6.1.1 참조).

2. 요구 사항

이 문서에 사용된 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 및 "OPTIONAL"이라는 핵심 단어들은 [RFC2119]에 설명된 대로 해석되어야 합니다.

3. 428 사전 조건 필요

428 상태 코드는 오리진 서버가 요청을 조건부로 만들 것을 요구함을 나타냅니다.

일반적으로 이는 클라이언트가 리소스의 상태를 GET으로 가져와 수정한 뒤 PUT으로 서버에 다시 보낼 때, 그 사이에 제3자가 서버의 상태를 변경하여 충돌이 발생하는 "손실된 업데이트(lost update)" 문제를 피하기 위해 사용됩니다. 서버가 요청을 조건부로 요구함으로써 클라이언트가 올바른 사본으로 작업하고 있음을 보장할 수 있습니다.

이 상태 코드를 사용하는 응답은 요청을 성공적으로 다시 제출하는 방법을 설명해야 합니다. 예를 들어:

HTTP/1.1 428 Precondition Required
Content-Type: text/html

<html>
   <head>
      <title>Precondition Required</title>
   </head>
   <body>
      <h1>Precondition Required</h1>
      <p>This request is required to be conditional; 
      try using "If-Match".</p>
   </body>
</html>

428 상태 코드를 포함한 응답은 캐시에 저장되어서는 안 됩니다.

4. 429 요청이 너무 많음

429 상태 코드는 사용자가 주어진 시간 동안 너무 많은 요청을 보냈음을 나타냅니다("요율 제한").

응답 표현은 상태를 설명하는 세부 정보를 포함해야 하며, 새 요청을 보낼 때까지 기다려야 하는 시간을 나타내는 Retry-After 헤더를 포함할 수 있습니다.

예를 들어:

HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600

<html>
   <head>
      <title>Too Many Requests</title>
   </head>
   <body>
      <h1>Too Many Requests</h1>
      <p>I only allow 50 requests per hour to this Web site per
         logged in user.  Try again soon.</p>
   </body>
</html>

이 사양은 오리진 서버가 사용자를 어떻게 식별하는지 또는 요청을 어떻게 집계하는지를 정의하지 않습니다. 예를 들어, 요청 비율을 제한하는 오리진 서버는 리소스별, 서버 전체, 또는 서버 집합 전반에 대해 요청 수를 기준으로 제한할 수 있습니다. 마찬가지로, 사용자를 인증 자격 증명이나 상태성 쿠키로 식별할 수도 있습니다.

429 상태 코드를 포함한 응답은 캐시에 저장되어서는 안 됩니다.

5. 431 요청 헤더 필드가 너무 큼

431 상태 코드는 서버가 요청의 헤더 필드가 너무 커서 요청을 처리하기를 꺼린다는 것을 나타냅니다. 요청 헤더 필드의 크기를 줄인 후 요청을 다시 제출할 수 있습니다.

이 상태 코드는 요청 헤더 필드들의 전체 집합이 너무 큰 경우와 단일 헤더 필드가 문제인 경우 모두에 사용할 수 있습니다. 후자의 경우 응답 표현은 어느 헤더 필드가 너무 컸는지 명시하는 것이 좋습니다.

예를 들어:

HTTP/1.1 431 Request Header Fields Too Large
Content-Type: text/html

<html>
   <head>
      <title>Request Header Fields Too Large</title>
   </head>
   <body>
      <h1>Request Header Fields Too Large</h1>
      <p>The "Example" header was too large.</p>
   </body>
</html>

431 상태 코드를 포함한 응답은 캐시에 저장되어서는 안 됩니다.

6. 511 네트워크 인증 필요

511 상태 코드는 클라이언트가 네트워크 접근을 얻기 위해 인증해야 함을 나타냅니다.

응답 표현은 사용자가 자격 증명을 제출할 수 있는 리소스에 대한 링크(예: HTML 양식)를 포함하는 것이 좋습니다.

511 응답은 도전(challenge)이나 로그인 인터페이스 자체를 포함해서는 안 됩니다. 브라우저는 로그인 인터페이스를 원래 요청된 URL과 연관된 것으로 표시할 수 있어 혼동을 일으킬 수 있기 때문입니다.

511 상태 코드는 오리진 서버에서 생성해서는 안 됩니다; 이는 네트워크 접근 제어 수단으로 중간에 개입하는 인터셉트 프록시가 사용하도록 의도된 것입니다.

511 상태 코드를 포함한 응답은 캐시에 저장되어서는 안 됩니다.

6.1. 511 상태 코드와 캡티브 포털

511 상태 코드는 소프트웨어(특히 비브라우저 에이전트)가 요청된 서버가 아니라 중간의 네트워크 인프라스트럭처로부터의 응답을 받는 상황에서 발생하는 문제를 완화하도록 설계되었습니다. 이는 캡티브 포털의 배치를 장려하려는 목적이 아니라, 그로 인한 피해를 제한하려는 목적입니다.

네트워크 운영자가 인증, 약관 동의 또는 기타 사용자 상호작용을 요구하려 할 때, 일반적으로 Media Access Control(MAC) 주소로 아직 인증하지 않은 클라이언트("알 수 없는 클라이언트")를 식별합니다.

알 수 없는 클라이언트는 모든 트래픽이 차단되며 TCP 포트 80의 트래픽만 인증용 HTTP 서버("로그인 서버")로 보내고, 물론 로그인 서버 자체로의 트래픽은 허용됩니다.

예를 들어, 사용자 에이전트는 네트워크에 연결한 후 TCP 포트 80에서 다음 HTTP 요청을 할 수 있습니다:

GET /index.htm HTTP/1.1
Host: www.example.com

이러한 요청을 수신하면 로그인 서버는 511 응답을 생성합니다:

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<html>
   <head>
      <title>Network Authentication Required</title>
      <meta http-equiv="refresh" 
            content="0; url=https://login.example.net/">
   </head>
   <body>
      <p>You need to <a href="https://login.example.net/">
      authenticate with the local network</a> in order to gain 
      access.</p>
   </body>
</html>

여기서 511 상태 코드는 비브라우저 클라이언트가 응답을 오리진 서버로부터 온 것으로 잘못 해석하지 않도록 보장하고, META HTML 요소는 사용자 에이전트를 로그인 서버로 리다이렉트합니다.

7. 보안 고려사항

7.1. 428 사전 조건 필요

428 상태 코드는 선택 사항입니다; 클라이언트는 "손실된 업데이트" 충돌을 방지하기 위해 이 상태 코드의 사용에 의존할 수 없습니다.

7.2. 429 요청이 너무 많음

서버가 공격을 받거나 단일 당사자로부터 매우 많은 요청을 받고 있을 때, 각각에 429 상태 코드로 응답하는 것은 자원을 소모합니다.

따라서 서버가 429 상태 코드를 사용하도록 요구되지는 않습니다; 자원 사용을 제한할 때는 연결을 단순히 드롭하거나 다른 조치를 취하는 것이 더 적절할 수 있습니다.

7.3. 431 요청 헤더 필드가 너무 큼

서버는 431 상태 코드를 사용하도록 요구되지 않습니다; 공격을 받는 경우 연결을 드롭하거나 다른 조치를 취하는 것이 더 적절할 수 있습니다.

7.4. 511 네트워크 인증 필요

일반적으로 511 상태 코드를 담은 응답은 요청의 URL에 표시된 오리진 서버에서 오지 않습니다. 이로 인해 많은 보안 문제가 발생합니다. 예를 들어, 공격하는 중간자는 원래 도메인 네임스페이스에 쿠키를 삽입하거나, 사용자 에이전트가 보내는 쿠키나 HTTP 인증 자격 증명을 관찰할 수 있습니다.

그러나 이러한 위험은 511 상태 코드만의 문제가 아닙니다; 즉, 이 상태 코드를 사용하지 않는 캡티브 포털도 동일한 문제를 일으킬 수 있습니다.

또한, SSL 또는 TLS 연결(일반적으로 포트 443)에서 이 상태 코드를 사용하는 캡티브 포털은 클라이언트에서 인증서 오류를 발생시킬 것임을 주의하십시오.

8. IANA 고려사항

HTTP 상태 코드 레지스트리는 다음 항목들로 업데이트되었습니다:

Value: 428
Description: Precondition Required
Reference: [RFC6585]

Value: 429
Description: Too Many Requests
Reference: [RFC6585]

Value: 431
Description: Request Header Fields Too Large
Reference: [RFC6585]

Value: 511
Description: Network Authentication Required
Reference: [RFC6585]

9. 참조

9.1. 규범 참조

[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2616]: Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

9.2. 참고 문헌

[CORS]: van Kesteren, A., Ed., “Cross-Origin Resource Sharing”, W3C Working Draft WD-cors-20100727, July 2010, <http://www.w3.org/TR/cors/>.
[Favicon]: Wikipedia, “Favicon”, March 2012, <http://en.wikipedia.org/w/index.php?title=Favicon&oldid=484627550>.
[OAuth2.0]: Hammer-Lahav, E., Ed., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol”, Work in Progress, March 2012.
[P3P]: Marchiori, M., Ed., “The Platform for Privacy Preferences 1.0 (P3P1.0) Specification”, W3C Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/P3P/>.
[RFC4791]: Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV)”, RFC 4791, March 2007.
[RFC4918]: Dusseault, L., Ed., “HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)”, RFC 4918, June 2007.
[WIDGETS]: Caceres, M., Ed., “Widget Packaging and XML Configuration”, W3C Recommendation REC-widgets-20110927, September 2011, <http://www.w3.org/TR/widgets/>.
[WebFinger]: WebFinger Project, “WebFingerProtocol (Draft)”, January 2010, <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>.

Appendix A. 감사의 글

Jan Algermissen과 Julian Reschke에게 제안과 피드백에 대해 감사드립니다.

Appendix B. 캡티브 포털이 제기한 문제

클라이언트가 포털의 응답과 의도한 HTTP 서버의 응답을 구별할 수 없기 때문에 여러 문제가 발생합니다. 511 상태 코드는 그중 일부를 완화하도록 의도되었습니다.

한 예로 브라우저가 접근하는 사이트를 식별하기 위해 일반적으로 사용하는 "favicon.ico" [Favicon]가 있습니다. 특정 사이트의 favicon이 캡티브 포털에서 가져와지는 경우(예: 사용자가 인증되지 않은 경우) 브라우저 캐시에 남아(대부분의 구현은 favicon을 공격적으로 캐시함) 포털 세션 이후에도 지속되어 포털의 favicon이 합법적인 사이트를 "점유한" 것처럼 보일 수 있습니다.

또 다른 브라우저 기반 문제는 Platform for Privacy Preferences [P3P]가 지원될 때 발생할 수 있습니다. 구현 방식에 따라 브라우저가 p3p.xml 파일에 대한 포털의 응답을 서버의 응답으로 해석하여 포털이 광고하는 개인정보 처리방침(또는 그 부재)이 의도한 사이트에 적용되는 것으로 해석될 수 있습니다. WebFinger [WebFinger], Cross-Origin Resource Sharing [CORS], Open Authorization [OAuth2.0] 등의 다른 웹 기반 프로토콜도 유사한 문제에 취약할 수 있습니다.

HTTP는 주로 웹 브라우저와 함께 사용되지만, 점점 더 많은 비브라우저 애플리케이션이 이를 기반 프로토콜로 사용하고 있습니다. 예를 들어 Web Distributed Authoring and Versioning(WebDAV) [RFC4918]와 Calendaring Extensions to WebDAV (CalDAV) [RFC4791]는 각각 원격 저작 및 캘린더링을 위해 HTTP를 사용합니다. 캡티브 포털 뒤에서 이러한 애플리케이션을 사용하는 경우 사용자에게 잘못된 오류가 표시되거나 심한 경우 콘텐츠 손상으로 이어질 수 있습니다.

유사하게, 위젯 [WIDGETS], 소프트웨어 업데이트, Twitter 클라이언트나 iTunes Music Store와 같은 기타 전문 소프트웨어 등 다른 비브라우저 애플리케이션들도 영향을 받을 수 있습니다.

HTTP 리디렉션을 사용하여 트래픽을 포털로 유도하면 이러한 문제가 해결된다고 믿는 경우가 있지만, 많은 사용자가 리디렉션을 "따르기" 때문에 이는 좋은 해결책이 아닙니다.

저자 주소

Mark Nottingham
Rackspace
Email: mnot@mnot.net
URI: http://www.mnot.net/

Roy T. Fielding
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA 95110
USA
Email: fielding@gbiv.com
URI: http://roy.gbiv.com/