RFC 7230 (HTTP/1.1)

Hypertext Transfer Protocol (HTTP/1.1) : Message Syntax and Routing

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.

1. Introduction

  • 1. “Message Syntax and Routing” (해당 문서)

  • 2. “Semantics and Content” [RFC7231]

  • 3. “Conditional Requests” [RFC7232]

  • 4. “Range Requests” [RFC7233]

  • 5. “Caching” [RFC7234]

  • 6. “Authentication” [RFC7235]

2. Architecture

HTTP는 World Wide Web (WWW) 아키텍처를 위해 만들어 졌고, 시간이 지남에 따라 월드 와이드 하이퍼텍스트 시스템의 확장성에 대한 요구들을 지원하기 위해 발전했다. 아키텍처의 대부분이 용어와 HTTP 정의를 위해 사용되는 구문들에 반영되었다.

2.1 Client/Server Messaging

HTTP는 신뢰성 있는 전송 계층 또는 세션 계층 “connection”의 (Section 6) 메시지 교환 (Section 3)에 의해 작동되는 상태없는 요청/응답 프로토콜이다. HTTP “client(이하 클라이언 트)” 는 하나 이상의 HTTP 요청들을 전송하기 위한 목적으로 커넥션을 서버에 설립하는 프로 그램이다. HTTP “server(이하 서버)”는 HTTP 요청을 처리하고 HTTP 응답을 보내기 위해 커넥션을 허용하는 프로그램이다.

  • user agent(이하 사용자 에이전트)

요청을 시작하는 다양한 클라이언트 프로그램 (브라우저, 스파이더 (웹 기반 로봇), 커맨드 라인 툴, 모바일 앱)

  • origin server(이하 원서버)

특정 대상 리소스에 대 한 권한 있는 응답을 생성할 수 있는 프로그램

다음 예시는 URI 에서 GET 요청을 위한 일반적인 메시지 교환을 보여준다.

"http://www.example.com/hello.txt":

클라이언트 요청:

GET /hello.txt HTTP/1.1 User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.71 zlib/1.2.3 Host: www.example.com Accept-Lanuage: en, mi

서버 응답:

HTTP/1.1 200 OK Date: Mon, 27 Jul 2009 12:28:53 GMT Server: Apache Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT ETag: "34aa387-d-1568eb00" Accept-Ranges: bytes Content-Length: 51 Vary: Accept-Encoding Content-Type: text/plain Hello World! My payload includes a trailing CRLF.

2.2 Implementation Diversity

보통의 HTTP 사용자 에이전트는 가정 애플리케이션, 음향기기, 체중계, 스크립트를 갱신하는 firmware, command-line 프로그램, 모바일 앱, 그리고 다양한 모양과 크기의 통신 기기를 포함한다. 마찬가지로, 보통의 HTTP 원 서버는 홈 자동화 장치, 네트워킹을 구성하는 부품, 사무용 기계, 자율 로봇, 뉴스 피드, 트래픽 카메라, 광고 선택자, 그리고 비디오-배송 플랫폼을 포함한다.

2.3 Intermediaries (중개자)

중개자의 3가지 형태

  • Proxy

  • Gateway (reverse proxy)

  • Tunnel: 메시지 변경없이 2개의 커넥션에 숨겨진 중개자로써 역할(ex, TLS)

용어: upstream, downstream, inbound, outbound

서버는 커넥션 이 보안되어 있고 해당 에이전트에 특정되어 있지 않는한 동일한 커넥션에 대한 두개의 요청 이 동일한 사용자 에이전트에서 온 것으로 가정해서는 안 된다. (MUST NOT)

2.4 Caches

"cache"는 이전 응답 메시지의 로컬 보관소이고 메시지의 저장, 검색, 삭제를 관리 하는 서브 시스템이다. 캐시는 캐시 가능한 응답을 저장하여 향후 동일한 요청에 대한 응답 시 간과 네트워크 대역폭 사용을 줄인다. 캐시는 서버가 터널 역할을 하는 동안에는 사용될 수 없지만 그것을 제외하고는 클라이언트, 서버 모두에서 사용 가능하다.

2.5 Conformance and Error Handling

  • 발신자는 발신자가 거짓이라는 의미를 전달하는 프로토콜 요소를 생성하면 안 된다.(MUST NOT)

  • 발신자는 ABNF 규칙에 대응하는 정의된 문법에 맞지 않는 프로토콜 요소를 생성하면 안 된다.(MUST NOT)

  • 지정된 메시 지 내에서, 발신자는 다른 역할(i.e., 해당 메시지에 발신자에게 없는 역할)의 참가자만 생성할 수 있는 프로토콜 요소나 구문 대안을 생성하면 안 된다.(MUST NOT)

  • 수신된 프로토콜 요소가 분석되었을 때, 수신자는 수신자의 역할에 해당하는 적정한 길이의 값과 분석할 수 있어야 하며 ABNF 규칙들에 대응하는 정의된 문법에 일치해야 한다.(MUST)

  • 최소한, 수신자는 다른 메시지의 동일한 프로토콜 요소에 대해 생성한 값만큼 프로토콜 요소 길이를 구문분석하고 처리할 수 있어야한다.(MUST)

  • 수신자는 수신자가 해당 의미론에 의해 암시된 것을 잘못 구현한다고 (경험이나 구성을 통해) 판단하지 않는 한, 수신자는 이 명세에 정의된 의미론에 따라 수신된 프로토콜 요소를 해석해야 한다.(MUST)

  • 달리 명시되지 않은 한, 수신자는 잘못된 구조에서 사용 가능한 프로토콜 요소를 복구하려고 시도할 수 있다.(MAY)

HTTP는 구현의 문맥 배치와 목적에 따라 적절한 길이가 매우 다양하기 때문에 대부분의 프로토콜 요소에 대해 특정한 길이 제한을 가지고 있지 않는다.

또한, HTTP는 보안에 직접적인 영향을 미치는 경우를 제외하고 특정 오류 처리 메커니즘을 정의하지 않는데, 프로토콜의 서로 다른 응용 프로그램에는 다른 오류 처리 전략 이 필요하기 때문이다.

예를 들어, 웹 브라우저는 Location 헤더 필드가 ABNF에 따라 구문 분석되지 않는 응답에서 투명하게 복구하기를 원하는 반면, 시스템 제어 클라이언트는 어떤 형 태의 오류 복구도 위험하다고 간주할 수 있다.

2.6 Protocol Versioning

Host와 Connection 헤더 필드는 HTTP/1.1준수 여부에 관계 없이 모든 HTTP/1.x구현에 의해 구현되어야 한다.

  • HTTP 메시지를 처리하는 중개자(즉, 터널 역할을 하는 중개자를 제외한 모든 중개자)는 전달 된 메시지로 자신의 HTTP-version을 전송해야 한다.(MUST)

  • 클라이언트의 major 버전이 서버에 의해 지원하는 가장 높은 버전보다 높지 않고 클라이언트가 가장 높은 버전을 호환하는 것으로 알려져 있다면 클라이언트는 가장 높은 버전과 동일한 요청버전을 전송해야 한다.(SHOULD) 클라이언트는 적합하지 않은 버전을 보내면 안된다.(MUST NOT)

  • 서버가 HTTP 규격을 잘못 구현한 것으로 알려진 경우, 그러나 클라이언트가 적어도 하나의 정상적인 요청을 시도하고 서버가 상위 요청 버전을 잘못 처리하는 응답 상태 코드 또는 헤더 필드를 통해 확인한 후에만 클라이언트가 하위 요청 버전을 보낼 수 있다.(MAY)

  • 서버는 서버가 구성된 가장 높은 버전과 동일한 응답 버전을 전송해야 하며 major 버전은 요청에 수신된 버전보다 작거나 같아야 한다.(SHOULD) 서버는 호환되지 않는 버전을 보내면 안 된 다.(MUST NOT)

  • 클라이언트가 HTTP 사양을 잘못 구현한 것으로 알려지거나 의심되는 경우(예:클라이언트가 버전 번호를 올바르게 구문 분석하지 못하거나 중개자가 프로토콜의 minor 버전이 주어진 것을 따르지 않을 때 HTTP 버전을 맹목적으로 전달하는 것으로 알려진 경우) 서버가 요청에 대해 HTTP/ 1.0 응답을 보낼 수 있다.(MAY) 하나 이상의 요청 헤더 필드(e.g., User-Agent)가 오류가 있는 것으로 알려진 클라이언트가 전송한 값과 고유하게 일치하는 경우와 같은 특정 클라이언트 속성에 의해 트리거 되지 않는 한 이러한 프로토콜 다운그레이드를 수행해서는 안 된다.(SHOULD NOT)

어떤 이유로든 서버는 클라이언트의 주요 프로토콜 버전 서비스를 거부하고자 하 는 경우 505(HTTP Version Not Supported)의 응답을 보낼 수 있다.

2.7 Uniform Resource Identifiers

Uniform Resource Identifiers (URIs) [RFC3986]은 리소스를 식별하는 수단으로 HTTP 전체에서 사용된다.

"URI-reference", "absolute-URI", “relative-part", "scheme", "authority", "port", "host", "path-abempty", “segment", "query", “fragment" 정의는 URI 일반 구문에서 채택되었다.

2.7.1 http URI scheme

  • 발신자(sender)는 호스트 식별자가 비어있는 상태로 “http" URI를 생성해서는 안 된다.(MUST NOT)

  • 이러 한 URI 참조를 처리하는 수신자는 유효하지 않은 것으로 거부해야 한다.(MUST)

HTTP는 전송 프로토콜과 독립적이지만, 이름 위임 프로세스는 권한을 설정하는 TCP에 의존하기 때문에 “http” scheme은 TCP기반 서비스에만 한정된다.

2.7.2 https URI scheme

“https” URI scheme는 잠재적으로 HTTP 원서버가 주어진 TLS-보안 커넥션을 위한 TCP 포트를 청취하는 것으로 계층적으로 관리된 네임 스페이스의 연계에 따라 식별자를 주조하는 목적으로 정의 된다.

  • TCP 포트 443의 포트 하위 구성 요소가 비어 있거나 지정되지 않은 경우를 제외하고 기본값이다. 사용자 에이전트는 첫 번째 HTTP 요청을 보내기 전에 end-to-end의 강력한 암호화 통해 원서버에 대한 커넥션이 안전한지 확인해야 한다.(MUST)

2.7.3 http and https URI Normalization and Comparison

포트가 scheme의 기본포트와 같다면, 일반적인 형태는 포트 하위 구성을 생략하는 것이.

OPTIONS 요청의 요청 대상으로 absolute 형식으로 사용하지 않을 경우, 빈 경로 구성 요소 "/"의 절대 경로와 같으므로, 일반적인 형식은 “/" 경로를 대신 제공하는 것이다.

scheme 과 호스트는 대소문자를 구분하지 않으며 일반적으로 소문자로 제공된다.

“reserved" 집합에 있는 문자 이외의 문자는 백분율로 인코딩된 octets와 동일하다. 일반적인 형식은 해당 문자를 인코딩하지 않는다.([RFC3986])

다음 세개의 URI는 동등하다.

http://example.com:80/~smith/home.html

http://EXAMPLE.com/%7Esmith/home.html

http://EXAMPLE.com:/%7esmith/home.html

Previous질문 사항Next3. Message Format

Last updated