HTTP 1.1 Reference - Message Syntax and Routing (1) (최종 수정 날짜 : 2021-03-10)

참고 자료

이병록님이 번역하신 HTTP 1.1 Message Syntax and Routing 번역본
https://roka88.dev/106
MDN Web Docs
https://developer.mozilla.org/ko/docs/Web/HTTP

이외 자료는 내용 중 링크 추가

틀린 내용, 부족한 내용 꼭 지적 부탁드립니다!

1. Introduction

HTTP는 정보 시스템을 위한 일반적인 인터페이스 프로토콜이다. HTTP는 제공되는 리소스 유형과 무관한 클라이언트에 균일한 인터페이스를 제공하여 서비스 구현 방법에 대한 세부 정보를 숨기도록 설계되었다. 마찬가지로, 서버는 각 클라이언트의 목적을 인식할 필요가 없다. HTTP 요청은 특정 클라이언트 또는 미리 결정된 어플리케이션 단계 순서와 연결되지 않고 단독으로 고려될 수 있다. 그 결과 많은 다양한 맥락에서 효과적으로 사용될 수 있고 구현이 시간이 지남에 따라 독립적으로 진화할 수 있는 프로토콜이다.

HTTP는 비 HTTP 정보 시스템 간에 통신 변환을 위한 중개 프로토콜로써 사용하기 위해 설계되었다. HTTP 프록시 및 게이트웨이는 다양한 프로토콜을 HTTP 서비스와 동일한 방법으로 클라이언트가 보고 조작할 수 있는 하이퍼텍스트 형식으로 변환하여 대체 정보 서비스에 대한 접근을 제공할 수 있다.

이러한 유연성의 결과 중 하나는 프로토콜이 인터페이스 뒤에서 발생하는 것으로 정의될 수 없다는 것이다. 대신, 우리는 수신된 통신, 수신인의 예상된 동작, 통신 구문을 정의하는 것으로 제한된다. 통신이 분리되어 고려되는 경우, 성공적인 행위는 서버가 제공하는 관찰 가능한 인터페이스의 해당 변경사항에 반영되어야 한다. 그러나 여러 클라이언트들가 병렬적으로, 교차 목적으로 작동할 수 있기 때문에, 우리는 단일 응답의 범위를 넘어서는 그러한 변화를 관찰할 수 있도록 요구할 수 없다.

이 문서는 HTTP에서 사용되거나 참조되는 아키텍처 요소를 설명하고, HTTP, HTTPS URI 구문을 정의하며, 전체 네트워크 운영 및 커넥션 관리를 설명하고, HTTP 메시지 프레임 및 전달 요구 사항을 정의한다. 우리의 목표는 메시지 의미론과 독립적인 HTTP 메시지 처리에 필요한 모든 메커니즘을 정의하여 메시지 분석기 및 메시지 전달 중개자에 대한 전체 요구 사항을 정의하는 것이다.

무슨 내용인지 아직 이해가 잘 안된다… 읽고나서 이해가 되면 설명을 덧붙이겠다.

2. Architecture

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

2.1. Client/Server Messaging

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

client와 server라는 용어들은 특정 커넥션에 대한 프로그램 수행의 역할만 의미한다. 동일한 프로그램이 일부 커넥션에서는 클라이언트 역할을 하고 다른 커넥션에서는 서버 역할을 할 수 있다.
user agent는 브라우저, 스파이터 (웹 기반 로봇), 커맨드 라인 툴, 커스텀 응용 프로그램, 그리고 모바일 앱을 포함해서 요청을 시작하는 다양한 클라이언트 프로그램을 말한다.
origin server는 특정 대상 리소스에 대한 권한 있는 응답을 생성할 수 있는 프로그램이다. sender(발신자)와 recipient(수신자)는 주어진 메시지를 전송하고 수신하도록 구현된 모든것들을 의미한다.

HTTP는 대상 리소스와 리소스들간의 관계를 나타내기 위해서 URI 표준에 의존한다. 인터넷 메일과 Multipurpose Internet Mail Extensions(MIME)에 의해 사용된 유사한 포멧으로 메시지는 전송된다.

대부분의 HTTP 통신은 URI로 식별된 일부 리소스의 representation을 위한 GET(검색 요청)로 구성된다. 가장 간단한 경우로 사용자 에이전트와 오리진 서버 사이의 단일 양방향 커넥션을 통해 이 작업을 수행할 수 있다.

           request >  
User Agent ==================== Origin Server
                     < response

클라이언트 HTTP 요청을 서버에 요청 메시지 형식, method, URI와 프로토콜 버전을 포함한 request-line을 시작으로, 요청 수정자, 클라이언트 정보, 표현 메타 데이터를 포함하는 헤더 필드와 헤더 영역의 끝을 알리는 빈줄 이후, 마지막으로 페이로드 본문을 포함하는 메시지 본문을 보낸다.

서버는 클라이언트의 요청에 하나 또는 다수의 HTTP 응답 메시지를 각각의 프로토콜 버전, 성공 또는 에러 코드, 원문으로 된 상태 코드를 포함한 status-line을 시작으로, 가능하다면 서버 정보, 리소스 메타 데이터와 representation 메타 데이터를 포함하는 헤더 필드를 헤더 부분의 끝을 나타내는 빈줄과 함께 포함하고, 마지막으로 페이로드 body를 포함한 메시지 본문으로 응답을 한다.

아래의 예시는 GET 요청을 위한 일반적인 메시지 교환을 나타낸다.

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

Client
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

Server : 
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 설계를 고려할 때, 모든 사용자 에이전트들이 범용 브라우저들이고 모든 오리진 서버들이 큰 규모의 공용 웹사이트라는 생각의 함정에 빠지는 것이 쉽다. 이것은 잘못된 생각이다. 보통의 HTTP 사용자 에이전트는 가정 어플리케이션, 음향기기, 체중계, 스크립트를 갱신하는 firmware, command-line 프로그램, 모바일 앱, 그리고 다양한 모양과 크기의 통신 기기를 포함한다. 마찬가지로, 보통의 HTTP 오리진 서버는 홈 자동화 장치, 네트워킹을 구성하는 부품, 사무용 기계, 자율 로봇, 뉴스 피드, 트래픽 카메라, 광고 선택자, 그리고 비디오-배송 플랫폼을 포함한다.

User Agent는 요청시 소프트웨어 에이전트와 직접적으로 상호작용하는 사용자가 있음을 의미하지 않는다. 대부분의 경우, 사용자 에이전트가 설치되거나 구성되어 백그라운드에서 실행되고 나중에 검사할 수 있도록 결과를 저장한다. (관심있 있거나 문제를 일으키는 결과 중 일부만 저장). 예시로 스파이더는 일반적으로 시작 URI가 주어지고, 웹을 하이퍼텍스트 그래프로 크롤링하는 동안 특정 행동을 따르도록 구성되었다.

HTTP의 구현 다양성은 모든 사용자 에이전트가 사용자에게 대화형 제안을 하거나 보안 또는 개인정보 보호 문제에 대한 적절한 경고를 제공할 수 없음을 의미한다. 이 규격에서 사용자에게 오류를 보고해야 하는 몇 가지 경우에는 오류 콘솔이나 로그파일에서만 이러한 보고를 관찰할 수 있다. 마찬가지로 사용자가 계속하기 전에 자동작업을 확인해야 하는 요구 사항은 사전 구성 선택, 런타입 옵션 또는 단순한 안전하지 않은 작업 회피로 충족될 수 있다. 확인은 사용자가 이미 선택한 경우 특정 사용자 인터페이스 또는 정상 처리 중단을 의미하지 않는다.

2.3. Intermediaries (중개인)

HTTP를 사용하면 커넥션 체인을 통해 요청을 충족할 수 있다. HTTP 중개자로 세가지 일반적인 형식이 있따. 프록시, 게이트웨이, 터널. 경우에 따라 단일 중개자가 오리진 서버, 프록시, 게이트웨이 또는 터널역할을 하여 각 요청의 특성에 따라 동작을 전환 할 수 있다.

   >      >      >      > 
UA ==== A ==== B ==== C ==== O
      <      <      <      <

위 그림은 사용자 에이전트와 오리진 서버 사이에 3개의 중개자 (A, B와 C)를 보여준다. 전체 체인을 이동하는 요청 또는 응답 메시지는 4개의 분리된 커넥션을 통해 전송된다. 일부 HTTP 통신 옵션들은 가장 가까운 터널이 아닌 인접 네트워크와의 커넥션에만 적용되거나 체인의 끝점에만 적용되거나 체인을 따라 있는 모든 커넥션에 적용될 수 있다. 다이어그램은 선형이지만, 각 참여자는 여러개의 동시 통신에 참여할 수 있다. 예를 들어 B는 A외에 여러 클라이언트로부터 요청을 받을 수 있거나 또는 같은 시간에 A의 요청을 다루면서 C이외에 서버로 요청을 전송할 수 있다. 마찬가지로 나중의 요청들은 로드 밸런싱을 통한 동적인 구성에 기반하여 커넥션의 다른 경로를 통해 전송될 것이다.

Upstream과 Downstream은 메시지 흐름의 관계에서 방향 요구사항들을 설명하기 위해 사용된다. 모든 메시지들은 Upstream으로 부터 Downstream으로 흐른다. Inbound와 Outbound는 요청 라우트의 관계에서 방향 요구사항들을 설명하기 위해 사용된다. Inbound는 오리진 서버로 향하는 것을 의미하고, Outbound는 사용자 에이전트로 향하는 것을 의미한다.

Proxy는 클라이언트가 일반적으로 로컬 구성 규칙들을 통해 선택한 메시지-전송 에이전트로, 일부 유형의 absolute URI에 대한 요청을 수신하고 HTTP 인터페이스를 통한 변환을 통해 해당 요청을 충족시키려고 시도한다. HTTP URI에 대한 프록시 요청과 같이 일부 번역은 최소 수준이지만 다른 요청은 완전히 다른 애플리케이션 레벨 프로토콜 간에 변환이 필요할 수 있다. 프록시들은 종종 보안적 이익, 주석 서비스, 또는 공유 캐시를 위한 공통 중개자로 조직의 HTTP 요청들을 그룹화 하는데 자주 사용된다. 일부 프록시들은 선택된 메시지 또는 페이로드가 전송되는 동안 변환을 적용하기 위해 설계 되었다.

추가적인 설명으로 인터넷의 다른 네트워크를 탐색 할 때 프록시 서버와 HTTP 터널은 WWW의 컨텐츠에 대한 엑세스를 용이하게 한다. 프록시는 사용자의 로컬 컴퓨터에 있거나 사용자의 컴퓨터와 인터넷의 대상 서버 사이에 있을 수 있다. 프록시는 포워드 프록시(터널, 게이트웨이)와 리버스 프록시(로드 밸런싱, 인증, 복호화, 캐싱을 위해 서버에 대한 엑세스를 제어하고 보호하는데 사용)의 두가지 유형이 있다.

포워드 프록시 정방향 프록시, 게이트웨이 또는 프록시는 클라이언트 또는 클라이언트 그룹에 프록시 서비스를 제공한다. 인터넷에는 수십만 개의 오픈 포워드 프록시가 있다. 그룹에서 사용하는 대역폭을 줄이고 제어하기 위해 DNS 또는 웹 페이지와 같은 인터넷 서비스를 저장하고 전달한다. 전달 프록시는 익명 프록시 일 수도 있으며 사용자가 웹을 검색하거나 다른 인터넷 서비스를 사용하는 동안 IP 주소를 숨길 수 있다. The Onion Router는 익명 성을 위해 여러 프록시를 통해 인터넷 트래픽을 라우팅한다.

리버스 프록시 이름에서 알 수 있듯이 리버스 프록시는 포워드 프록시가 수행하는 작업과 반대로 수행한다. 포워드 프록시는 클라이언트(또는 요청 호스트)를 대신하여 작동한다. 포워드 프록시는 클라이언트 ID를 숨길 수 있는 반면 리버스 프록시는 서버의 ID를 숨길 수 있다. 리버스 프록시는 사용 사례는 아래와 같다.

로드 밸런싱 : 로드를 여러 웹 서버에 분산
정적 컨텐츠 캐시 : 사진과 같은 정적 컨텐츠를 캐싱하여 웹 서버를 오프로드 한다.
압축 : 컨텐츠를 압축하고 최적화하여 로드 시간을 단축한다.

Gateway는 (reverse proxy) 아웃바운드 커넥션을 위한 오리진 서버로써 역할을 하지만, 수신된 요청을 다른 서버로 변환하여 인바운드로 전송하는 중간 서버 역할을 한다. 게이트웨이는 오래된 또는 신뢰 할 수 없는 정보 서비스들을 캡슐화 하는데 사용 되며, 서버의 성능을 향상 시키기 위해 accelerator 캐싱, 그리고 파티셔닝 또는 여러 시스템 간의 HTTP 서비스의 로드 밸런싱을 할 수 있게 사용된다.

오리진 서버에 적당한 모든 HTTP 요구사항은 게이트웨이의 아웃바운드 통신에도 적용된다. 게이트웨이는 private extensions(개인적으로 프로토콜을 확장한 것들)을 이 명세의 범위 밖의 HTTP에 포함하여 원하는 프로토콜을 사용하여 인바운드 서버와 통신한다. 그러나 서드파티 HTTP 서버들과 상호작용하는 HTTP-to-HTTP 게이트 웨이는 게이트웨이의 인바운드 커넥션에 대한 사용자 에이전트의 요구사항에 준수해야 한다.

Tunnel은 메시지 변경없이 2개의 커넥션에 숨겨진 중개자로써 역할을 한다. 터널이 활성되면, HTTP 요청에 의해 시작되었을 수 있지만, 터널은 HTTP 통신의 당사자로 고려되지 않는다. 두 끝점에서 전달하는 커넥션이 종료되면 터널은 더 이상 존재하지 않는다. 공유 방화벽 프록시를 통해 기밀 통신을 설정하는데 전송층 보안(TLS)이 사용되는 경우와 같이 중계를 통해 가상 커넥션을 확장하는데 터널이 사용된다.

중개자를 위한 범주는 HTTP 통신의 참가자로써 역할만 고려됐다. 또한 네트워크 프로토콜 스택의 하위 계층에서 행동하여 메시지 보낸 사람의 확인이나 허가 없이 HTTP 트래픽을 필터링하거나 리다이렉트 할 수 있는 중개자도 있다. 네트워크 중개자들은 중간자 공격(프로토콜 단계에서)을 구분할 수 없으며, 실수로 HTTP 의미론을 위반하여 보안 결함 또는 상호 운용성 문제를 야기하는 경우가 많다.

예를 들어, interception proxy(transparent proxy로 알려진)는 클라이언트에 의해서 선택되지 않았기 때문에 HTTP 프록시와 다르다. 대신에, interception proxy는 외부의 TCP 포트 80 패킷 (그리고 가끔 다른 일반적인 포트 트래픽)을 거르거나 또는 리다이렉트 한다. interception proxy는 일반적으로 로컬이 아닌 인터넷 서비스 사용을 허용하기 전에 계정 가입을 적용하는 수단으로 공용 네트워크 엑세스 지점에서, 네트워크 사용정책을 시행하기 위해 회사 방화벽 내에서 발견 된다.

HTTP는 상태 없는 프로토콜로 정의되었고, 각 요청 메시지는 개별적으로 이해될 수 있다는것을 의미한다. 대부분의 구현은 프록시된 커넥션을 재사용하거나 또는 여러 서버간에 동적으로 로드 밸런스 요청을 하기 위해 HTTP의 상태 없는 설계에 의존한다. 따라서 서버는 커넥션이 보안되어 있고 해당 에이전트에 특정되어 있지 않는한 동일한 커넥션에 대한 두개의 요청이 동일한 사용자 에이전트에서 온 것으로 가정해서는 안 된다. 일부 비표준 HTTP 확장들은 이 요구사항을 위반하고, 보안 및 상호작용 문제를 발생시킨다.

2.4. Caches

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

캐시의 효과는 체인의 참여자 중 하나가 해당 요청에 적용할 수 있는 캐시된 응답을 가지고 있는 경우 요청/응답 체인이 단축 되는 것이다. 다음은 B가 UA 또는 A에 의해 캐시되지 않은 요청에 대한 O(경유 C)의 이전 응답의 캐시된 사본을 가지고 있는 경우의 결과 체인을 보여준다.

   >      >
UA ==== A ==== B ---- C ---- O
      <      <

캐시가 후속 요청에 응답하기 위해 응답 메시지의 복사본을 저장할 수 있는 경우 응답은 “cacheable”이다. 응답을 캐시할 수 있는 경우에도 캐시된 응답을 특정 요청에 사용할 수 있는 경우 클라이언트 또는 원서버에 의해 추가 제약이 있을 수 있다.

월드 와이드 웹과 대규모 조직에 걸쳐 배치된 캐시의 설계와 구성은 매우 다양하다. 대양을 횡단하는 대역폭을 아끼기 위한 프록시 캐시의 국가 계층 구조, 브로드 캐스트 또는 멀티 캐스트 캐시 엔트리를 위한 협업 시스템, 오프라인 또는 high-latency 환경들에서 사용하기 위한 pre-fetched 캐시 엔트리의 아카이브 등이 포함된다.

2.5. Conformance and Error Handling

이 명세는 HTTP 통신의 참여자의 규칙에 따라 적합성 기준을 대상으로 한다. 따라서 HTTP 요구사항은 어떤 행동이 요구사항에 의해 제한되고 있는지에 따라서 발신자, 수신자, 클라이언트, 서버, 사용자 에이전트, 중개자, 원서버, 프록시, 게이트웨이, 또는 캐시가 배치되어 있다. 구현, 리소스 소유자 및 프로토콜 요소 등록이 단일 통신 범위를 벗어나 적용되는 경우 추가 (관행적) 요구 사항이 적용된다.

동사 Generate는 프로토콜 요소를 생성하는 것과 단지 수신된 요소를 다운스트림에서 전달하는 것 사이에서 요구사항이 구별되는 Send 대신 사용 된다.

구현은 HTTP에 맞는 규칙들과 관련된 모든 요구사항들을 따른다면, 적합한 것으로 간주 된다.

적합성은 구문과 프로토콜 요소의 의미론을 둘 다 포함한다. 발신자는 발신자가 거짓이라는 알려진 의미를 전달하는 프로토콜 요소를 생성하면 안 된다. 발신자는 ABNF 규칙에 대응하는 정의된 문법에 맞지 않는 프로토콜 요소를 생성하면 안 된다. 지정된 메시지 내에서, 발신자는 다른 역할(i.e., 해당 메시지에 발신자에게 없는 역할)의 참가자만 생성할 수 있는 프로토콜 요소나 구문 대안을 생성하면 안 된다.

수신된 프로토콜 요소가 분석되었을 때, 수신자는 수신자의 역할에 해당하는 적정한 길이의 값과 분석할 수 있어야 하며 ABNF 규칙들에 대응하는 정의된 문법에 일치해야 한다. 참고로, 일부 수신된 요소들은 분석 되지 않을 수 있다. 예를 들어 메시지를 전송하는 중개자는 일반 Field-name과 Field-value 성분들의 header-field를 분석할 수 있고, field-value의 추가적인 분석 없이 헤더 필드를 전송하는 것도 있다.

HTTP 구현의 문맥 배치와 목적에 따라 적절한 길이가 매우 다양하기 때문에 대부분의 프로토콜 요소에 대해 특정한 길이 제한을 가지고 있지 않는다. 따라서, 발신자와 수신자 사이의 상호작용은 각 프로토콜 요소를 위한 적정한 길이가 무엇인지에 관한 공유된 예상에 의존한다. 게다가 일부 프로토콜 요소에 대해 일반적으로 적절한 길이로 이해되는 것은 지난 20년 동안 HTTP 사용과정에서 바뀌었으며 앞으로도 계속 변화할것이다.

최소한, 수신자는 다른 메시지의 동일한 프로토콜 요소에 대해 생성한 값만큼 프로토콜 요소 길이를 구문 분석하고 처리할 수 있어야 한다. 예를 들어 자체 리소스에 매우 긴 URI 참조를 게시하는 오리진 서버는 요청 대상으로 수신될 때 동일한 참조를 구문 분석하고 처리할 수 있어야 한다.

수신자는 수신자가 해당 의미론에 의해 암시된 것을 잘못 구현한다고 (경험이나 구성을 통해) 판단하지 않는 한, 수신자는 이 명세에 정의된 의미론에 따라 수신된 프로토콜 요소를 해석해야 한다. 예를 들어 User-Agent 헤더 필드 검사에서 특정 콘텐츠 코딩을 수신할 때 실패한 것으로 알려진 특정 구현 버전을 나타내는 경우 오리진 서버는 수신된 Accept-Encoding 헤더 필드의 내용을 무시할 수 있다.

달리 명시되지 않은 한, 수신자는 잘못된 구조에서 사용 가능한 프로토콜 요소를 복구하려고 시도할 수 있다. HTTP는 보안에 직접적인 영향을 미치는 경우를 제외하고 특정 오류 처리 메커니즘을 정의하지 않는데, 프로토콜의 서로 다른 응용 프로그램에는 다른 오류 처리 전략이 필요하기 때문이다. 예를 들어 웹브라우전느 Location 헤더 필드가 ABNF에 따라 구문 분석되지 않는 응답에서 투명하게 복구하기를 원하는 반면, 시스템 제어 클라이언트는 어떤 형태의 오류 복구도 위험하다고 간주할 수 있다.

2.6. Protocol Versioning

HTTP는 “."를 프로토콜의 버전의 번호를 표시하기 위해 사용한다. 이 규격은 버전 1.1을 정의한다. 프로토콜 버전 전체는 발신자가 해당 버전의 HTTP 사양에 명시된 요건 집합을 준수하고 있음을 나타낸다.

HTTP 메시지 버전은 메시지의 첫번째 행에 HTTP-version 필드로 표시된다. HTTP-version은 대 소문자를 구분한다.

HTTP-Version = HTTP-name "/" DIGIT "." DIGIT
HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive

HTTP 버전 번호는 “.”로 구분된 두개의 10진수로 구성된다. 첫번째 숫자 (major)는 HTTP 메시징 구문을 나타내고, 두번째 숫자(minor)는 발신자에 적합하고 이후 통신을 이해할 수 있는 해당 major버전 내에서 가장 높은 minor 버전을 나타낸다. minor 버전은 발신자가 역으로 호환되는 프로토콜의 하위 집합만 사용하는 경우에도 발신자의 통신 기능을 알리므로 수신자는 더 많은 고급 기능을 응답 또는 향후 요청에 사용할 수 있음을 알수 있다.

HTTP/1.1 메시지가 HTTP/1.0 수신자 또는 버전을 알 수 없는 수신자에게 전송 될때, HTTP/1.1 메시지는 새로운 기능이 모두 무시될 경우 유효한 HTTP/1.0 메시지로 해석될 수 있도록 구성된다. 이 규격은 수신자가 HTTP/1.1을 지원하는 구성 또는 메시지 수신을 결정할 때까지 호환 가능한 기능만 사용하도록 일부 새 기능에 대한 recipient-version 요구 사항을 지정합니다.

헤더 필드의 해석은 동일한 major HTTP 버전과 minor 버전 간에 변경되지 않지만 이러한 필드가 없는 경우 수신자의 기본 동작은 변경될 수 있다. 별도로 지정하지 않는 한, HTTP/1.1에 정의된 헤더 필드는 모든 버전의 HTTP/1.x에 대해 정의된다. 특히, Host와 Connection 헤더 필드는 HTTP/1.1 준수 여부에 관계 없이 모든 HTTP/1.x 구현에 의해 구현되어야 한다.

새로운 헤더 필드는 프로토콜 버전을 변경하지 않고 도입될 수 있다. 새로운 헤더 필드의 정의된 의미론은 그것들을 인식하지 못하는 수신자들에 의해 새로운 헤더 필드를 안전하게 무시할 수 있게 해 준다.

HTTP 메시지를 처리하는 중개자(즉, 터널 역할을 하는 중개자를 제외한 모든 중개자)는 전달된 메시지로 자신의 HTTP-version을 전송해야 한다. 해당 메시지의 프로토콜 버전이 해당 중개자가 메시지 수신 및 전송을 모두 준수하는 버전과 일치하는지 확인하지 않고 HTTP 메시지의 첫 줄((request-line, response-line)을 맹목적으로 포워딩하는 것이 허용되지 않는다. 다운스트림 수신인이 메시지 발신인 버전을 사용하여 해당 발신인과의 이후 통신에 사용할 수 있는 기능을 결정할 때 HTTP 버전을 다시 작성하지 않고 HTTP 메시지를 전달하면 통신 오류가 발생할 수 있다.

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

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

서버는 서버가 구성된 가장 높은 버전과 동일한 응답 버전을 전송해야 하며 major 버전은 요청에 수신된 버전보다 작거나 같아야 한다. 서버는 호환되지 않는 버전을 보내면 안 된다. 어떤 이유로든 서버는 클라이언트의 주요 프로토콜 버전 서비스를 거부하고자 하는 경우 505(HTTP Version Not Supported)의 응답을 보낼 수 있다.

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

HTTP의 버전 관리 설계의 목적은 호환되지 않는 메시지 구문이 도입될 때만 큰 숫자가 증가하며, 프로토콜 변경이 메시지 의미론을 추가하거나 발신자의 추가 기능을 의미할 때만 작은 숫자가 증가한다.

HTTP 메시지가 수신자가 구현한 major 버전 번호로 수신되지만 수신자가 구현한 버전보다 높은 minor 버전 번호로 수신되면 수신자는 수신자가 확인할 수 있는 major 버전 내에서 가장 높은 major 버전에 있는 것처럼 메시지를 처리해야 한다. 수신자는 메시지가 해당 상위 버전에 대한 지원을 아직 표시하지 않은 수신자에게 보낼 때 동일한 major 버전의 구현에서 안전하게 처리할 수 있을 만큼 충분히 역호환 된다고 할 수 있다.

2.7.1. http URI scheme

지정된 포트에서 TCP 커넥션을 청취하는 잠재적 HTTP 오리진 서버에 의해 관리되는 계층 네임 스페이스에 따라 식벽자를 해석하기 위한 목적으로 “HTTP” URI scheme가 정의되어 있다.

http-URI = "http:" "//" authority path-abempty ["?" query]
          ["#" fragment]

“http” URI를 위한 오리진 서버는 호스트 식별자와 선택적 TCP 포트를 포함하는 권한 구성 요소로 식별된다. 계층 경로 구성 요소 및 선택적 쿼리 구성 요소는 해당 오리진 서버의 네임 스페이스 내에서 잠재적인 대상 리소스의 식별자 역할을 한다. 선택적 단편화 구성 요소를 사용하면 URI scheme와 독립적으로 보조 리소스를 간접적으로 식별할 수 있다.

발신자는 호스트 식별자가 비어있는 상태로 “http” URI를 생성해서는 안 된다. 이러한 URI 참조를 처리하는 수신자는 유효하지 않은 것으로 거부해야 한다.

http://:8080/example
이런거 안됨

호스트 식별자가 IP 주소로 제공되는 경우 오리진 서버는 해당 IP주소의 지정된 TCP 포트에서 청취자(패킷을 읽기 위해 대기)가 된다. 호스트가 등록된 이름인 경우 등록된 이름은 해당 오리진 서버의 주소를 찾기 위해 DNS와 같은 서비스와 함께 사용할 간접 식별자이다. 포트 하위 구성 요소가 비어 있거나 지정되지 않은 경우 TCP 포트 80(WWW 서비스용 예약 포트)이 기본 값이다.

참고로 주어진 권한 구성 요소와 함계 URI가 있다고 해서 해당 호스트 및 포트에서 항상 HTTP 서버가 커넥션을 청취한다는 의미는 아니다. 누구나 URI를 만들 수 있다. 권한 구성 요소는 누가 식별된 리소스를 대상으로 하는 요청에 대해 인증적으로 응답할 권한이 있는지를 결정한다. 등록된 이름 및 IP주소의 위임된 특성은 HTTP 서버의 존재 여부에 관계 없이 지정된 호스트 및 포트에 대한 제어를 기반으로 결합 네임 스페이스를 생성한다.

지정된 리소스에 대한 접근을 요구하는 컨텍스트 내에서 “http” URI를 사용하는 경우 클라이언트는 IP주소에 대한 호스트를 확인하고 지정된 포트의 해당 주소에 TCP 커넥션을 설정하고 URI의 식별 데이터가 포함된 HTTP 요청 메시지를 서버에 보내 접근 시도할 수 있다. 서버가 non-interim HTTP 응답 메시지와 요청을 응답 한다면, 그 응답은 클라이언트 요청에 대한 신뢰할 수 있는 답변으로 간주된다.

HTTP는 전송 프로토콜과 독립적이지만, 이름 위임 프로세스는 권한을 설정하는 TCP에 의존하기 때문에 “http” scheme은 TCP기반 서비스에만 한정 된다. “https” scheme가 종단간 보안 커넥션이 필요한 리소스에 사용되는 것처럼, 일부 다른 기본 커넥션 프로토콜에 기반한 HTTP 서비스도 다른 URI shceme를 사용하여 식별될 수 있다. “http”로 식별된 리소스에 대한 접근을 제고아기 위해 다른 프로토콜을 사용할 수도 있다. 이것은 TCP에만 해당하는 권한 있는 인터페이스이다.

권한에 대한 URI 일반 구문에는 URI에 사용자 인증 정보를 포함하기 위해 더 이상 사용되지 않는 userinfo 하위 구성요소도 포함된다. 일부 구현에서는 명령 호출 옵션, 구성 파일, 등의 인증 정보의 내부 구성에 userinfo 구성 요소를 사용한다. 또는 북마크 목록을 표시할 수도 있다. 이러한 사용으로 인해 사용자 ID 또는 암호가 노출될 수도 있다. 메시지 내에서 “http” URI 참조가 요청 대상 또는 헤더 필드 값으로 생성되는 경우 보낸 사람은 userinfo 하위 구성요소(및 해당 “@” 구분 기호)를 생성해서는 안 된다. 신뢰할 수 없는 소스에서 수신한 “http” URI 참조를 사용하기 전에 수신자는 userinfo에 대해 구문 분석하고 이 참조의 존재를 오류로 간주해야 한다. 피싱 공격을 위해 권한을 숨기는데 사용될 가능성이 높다.

2.7.2. https URI Scheme

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

위에서 설명한 “http” scheme에 대한 모든 요구 사항도 “https” scheme에 대한 요구 사항이다. TCP 포트가 지정되지 않은 경우 443이 기본값이며 사용자 에이전트는 첫 번째 HTTP 요청을 보내기 전에 강력한 암호화 사용, end-to-end 통해 오리진 서버에 대한 커넥션이 안전한지 확인해야 한다.

https-URI = "https" "//" authority path-abempty ["?" query]
            ["#" fragment]

참고로 “https” URI scheme는 권한을 설립하기 위해 TLS와 TCP 모두에 따라 달라진다. “https” scheme를 통해 사용 가능한 리소스는 리소스 식별자가 동일한 권한(동일한 TCP 포트를 수신하는 동일한 호스트)을 나타내더라도 “http” scheme와 identity를 공유하지 않도록 만든다. 그것들은 별개의 네임 스페이스이고, 별개의 오리진 서버로 간주된다. 그러나 Cookie 프로토콜과 같은 전체 호스트 도메인에 적용하도록 정의된 HTTP에 확장은 호스트 도메인 그룹 내의 다른 서비스와의 통신에 영향을 주기 위해 하나의 서비스에 의해 정보 집합을 허용할 수 있다.

2.7.3. http and https URI Normalization and Comparison

“http” 및 “https” scheme은 URI 일반 구문을 준수하기 때문에 이러한 URI들은 각 scheme에 의해 설명된 기본 값을 사용하며, 정의된 알고리즘을 따라 정규화 되고 비교된다.

포트가 scheme의 기본포트와 같다면, 일반적인 형태는 포트 하위 구성을 생략하는 것이다. OPTIONS 요청의 요청 대상으로 absolute 형식으로 사용하지 않을 경우, 빈 경로 구성 요소는 “/”의 절대 경로와 같으므로, 일반적인 형신은 “/” 경로를 대신 제공하는 것이다. scheme와 호스트는 대 소문자를 구분하지 않으며 일반적으로 소문자로 제공된다. 다른 모든 구성 요소는 대 소문자를 구분하여 비교된다. “reserved” 집합에 있는 문자 이외의 문자는 백분율로 인코딩된 octets와 동일하다. 일반적인 형식은 해당 문자를 인코딩하지 않는다.

http://example.com:80/~smith/home/html
http://EXAMPLE.com/%7Esmith/home/html
http://EXAMPLE.com:/%7esmith/home/html

위 3개의 URI는 모두 동등하다

PREVIOUSHTTP 1.1 Reference - Semantics and Content (5) (최종 수정 날짜 : 2021-02-25)

NEXTHTTP 1.1 Reference - Message Syntax and Routing (2) (최종 수정 날짜 : 2021-03-11)