HTTP/1.1

이 문서에서 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"는 모두 대문자로 표시된 경우에만 BCP 14 [RFC2119] 및 [RFC8174]에 설명된 대로 해석된다.

적합성 기준 및 오류 처리에 관한 고려사항은 Section 2 of [HTTP]에 정의되어 있다.

이 명세서는 [RFC5234]의 확장된 Backus-Naur 형식(ABNF)을 사용하며, 대소문자 구분 문자열 표기를 위해 [RFC7405]에 정의된 표기법을 확장하여 사용한다.

또한 Section 5.6.1 of [HTTP]에 정의된 목록 확장도 사용하여 "#" 연산자를 통해 쉼표로 구분된 목록을 간결하게 정의할 수 있다(이는 "*" 연산자가 반복을 나타내는 방식과 유사하다). 부록 A에는 모든 목록 연산자가 표준 ABNF 표기법으로 확장된 수집된 문법이 표시되어 있다.

관례상, "obs-"로 접두어가 붙은 ABNF 규칙 이름은 역사적 이유로 남아 있는 구식 문법 규칙을 나타낸다.

다음의 핵심 규칙들은 [RFC5234] 및 해당 부록에 정의된 참조로 포함된다: ALPHA (문자), CR (캐리지 리턴), CRLF (CR LF), CTL (제어 문자), DIGIT (10진수 0-9), DQUOTE (따옴표), HEXDIG (16진수 0-9/A-F/a-f), HTAB (수평 탭), LF (라인 피드), OCTET (임의의 8비트 데이터), SP (공백), 및 VCHAR (표시 가능한 [USASCII] 문자).

  BWS           = <BWS, see [HTTP], Section 5.6.3>
  OWS           = <OWS, see [HTTP], Section 5.6.3>
  RWS           = <RWS, see [HTTP], Section 5.6.3>
  absolute-path = <absolute-path, see [HTTP], Section 4.1>
  field-name    = <field-name, see [HTTP], Section 5.1>
  field-value   = <field-value, see [HTTP], Section 5.5>
  obs-text      = <obs-text, see [HTTP], Section 5.6.4>
  quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
  token         = <token, see [HTTP], Section 5.6.2>
  transfer-coding =
                  <transfer-coding, see [HTTP], Section 10.1.4>

  absolute-URI  = <absolute-URI, see [URI], Section 4.3>
  authority     = <authority, see [URI], Section 3.2>
  uri-host      = <host, see [URI], Section 3.2.2>
  port          = <port, see [URI], Section 3.2.3>
  query         = <query, see [URI], Section 3.4>

HTTP/1.1 메시지는 start-line 다음에 CRLF가 오고 그 뒤에 인터넷 메시지 형식과 유사한 형태의 옥텟 시퀀스로 구성된다: 0개 이상의 헤더 필드 행(통칭하여 "헤더" 또는 "헤더 섹션"), 헤더 섹션의 끝을 나타내는 빈 줄, 그리고 선택적인 메시지 본문.

  HTTP-message   = start-line CRLF
                   *( field-line CRLF )
                   CRLF
                   [ message-body ]

메시지는 클라이언트에서 서버로의 요청이거나 서버에서 클라이언트로의 응답일 수 있다. 문법적으로 두 종류의 메시지는 오직 start-line에서만 차이가 나며, 이는 요청의 경우 request-line이고 응답의 경우 status-line이며, 메시지 본문의 길이를 결정하는 알고리즘(Section 6)도 다르다.

  start-line     = request-line / status-line

이론적으로는 클라이언트가 요청을 받고 서버가 응답을 받는 상황이 발생할 수 있으며, 시작 행 형식의 차이로 구별할 수 있다. 하지만 실제로 서버는 요청만을 예상하도록 구현되어 있으며(응답은 알 수 없거나 잘못된 요청 메서드로 해석됨), 클라이언트는 응답만을 예상하도록 구현된다.

HTTP은 MIME(다목적 인터넷 우편 확장)의 일부 프로토콜 요소를 활용한다. HTTP와 MIME 메시지의 차이점은 부록 B를 참조하라.

HTTP 메시지를 구문 분석하는 일반 절차는 start-line을 구조체로 읽고, 빈 줄이 나오기 전까지 각 헤더 필드 행을 필드 이름으로 해시 테이블에 읽어 들인 다음, 구문 분석된 데이터를 사용하여 메시지 본문이 예상되는지 판단하는 것이다. 메시지 본문이 표시된 경우, 메시지 본문 길이에 해당하는 옥텟 수가 읽히거나 연결이 종료될 때까지 스트림으로 읽는다.

수신자는 MUST US-ASCII의 상위 집합인 인코딩으로 표현된 옥텟 시퀀스로 HTTP 메시지를 구문 분석해야 한다. 특정 인코딩을 고려하지 않고 유니코드 문자 스트림으로 HTTP 메시지를 구문 분석하면 LF (%x0A)를 포함한 잘못된 다바이트 문자 시퀀스를 문자열 처리 라이브러리가 다르게 처리하는 방식으로 인해 보안 취약점이 발생한다. 문자열 기반 파서는 메시지에서 요소를 추출한 이후에만 안전하게 사용될 수 있다(예: 메시지 구문 분석이 개별 필드 행을 구분한 후 헤더 필드 값 내부에서 사용).

start-line과 필드의 행 종결자는 CRLF 시퀀스이지만, 수신자는 단일 LF를 행 종결자로 인식하고 앞선 CR을 무시할 수 있다.

송신자는 콘텐츠 이외의 프로토콜 요소 내에서 LF 바로 앞에 오지 않는 단독 CR(즉, LF 없이 오는 CR)을 생성해서는 안 된다. 그러한 단독 CR을 받은 수신자는 해당 요소를 무효로 간주하거나 각 단독 CR을 SP로 대체한 후 요소를 처리하거나 메시지를 전달해야 한다.

초기 HTTP/1.0 사용자 에이전트 구현체는 일부 초기 서버 애플리케이션이 라인 종료로 끝나지 않는 메시지 본문을 읽지 못하는 문제를 우회하기 위해 POST 요청 후 추가 CRLF를 보낼 수 있었다. HTTP/1.1 사용자 에이전트는 요청 앞뒤에 추가 CRLF를 두어서는 안 된다. 요청 메시지 본문을 라인 종료로 끝내려면, 사용자 에이전트는 종료 CRLF 옥텟을 메시지 본문 길이의 일부로 계산해야 한다.

견고성을 위해 요청 행을 수신하고 구문 분석할 것으로 예상되는 서버는 요청 행 전에 수신된 적어도 하나의 빈 행(CRLF)을 무시하는 것이 바람직하다.

송신자는 start-line과 첫 번째 헤더 필드 사이에 공백을 보내서는 안 된다.

start-line과 첫 번째 헤더 필드 사이에 공백이 포함된 수신자는 메시지를 무효로 거부하거나 공백으로 시작하는 각 행을 추가 처리 없이 소비해야 한다(즉, 적절한 형식의 헤더 필드가 수신되거나 헤더 섹션이 종료될 때까지 공백으로 시작하는 행과 그 뒤를 따르는 모든 행을 무시). 무효한 공백 선행 행을 거부하거나 제거하는 것은 이후 수신자가 요청 스머글링(Section 11.2) 또는 응답 분할(Section 11.1) 공격에 취약할 수 있는 다운스트림 수신자에 의해 잘못 해석되는 것을 방지하기 위해 필요하다.

오직 HTTP 요청 메시지만을 수신하도록 대기하거나 start-line 상으로 HTTP 요청 메시지로 보이는 것을 처리하는 서버가, 위에서 언급한 견고성 예외를 제외하고 HTTP-메시지 문법과 일치하지 않는 옥텟 시퀀스를 수신하면, 서버는 400 (Bad Request) 응답을 보내고 연결을 닫는 것이 바람직하다.

HTTP은 "<major>.<minor>" 표기법을 사용하여 프로토콜 버전을 표시한다. 이 명세서는 버전 "1.1"을 정의한다. Section 2.5 of [HTTP]는 HTTP 버전 번호의 의미를 지정한다.

HTTP/1.x 메시지의 버전은 start-line의 HTTP-version 필드로 표시된다. HTTP-version은 대소문자를 구분한다.

  HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
  HTTP-name     = %s"HTTP"

HTTP/1.1 메시지가 HTTP/1.0 수신자 [HTTP/1.0] 또는 버전을 알 수 없는 수신자에게 전송될 때, HTTP/1.1 메시지는 모든 새로운 기능이 무시될 경우 유효한 HTTP/1.0 메시지로 해석될 수 있도록 구성된다. 이 명세서는 일부 새로운 기능에 대해 수신자 버전 요구사항을 부과하므로, 적합한 송신자는 구성이나 수신된 메시지를 통해 수신자가 HTTP/1.1을 지원한다고 판단하기 전까지 호환 가능한 기능만 사용한다.

HTTP 메시지를 처리하는 중계자(터널로 동작하는 중계자를 제외한 모든 중계자)는 전달된 메시지에서 자신의 HTTP-version을 보내야 하며, 업스트림 문제에 대한 우회 수단으로 의도적으로 다운그레이드 하는 경우를 제외한다. 다시 말해, 중계자는 수신 및 전송 측 모두에서 해당 중계자가 준수하는 버전과 일치하도록 메시지의 프로토콜 버전을 확인하지 않고 start-line을 무작정 전달해서는 안 된다. HTTP-version을 재작성하지 않고 메시지를 전달하면, 다운스트림 수신자가 이후 해당 송신자와의 통신에서 어떤 기능을 안전하게 사용할 수 있는지 판단할 때 통신 오류를 초래할 수 있다.

서버는 클라이언트가 사양을 잘못 구현하여 이후 버전의 응답을 올바르게 처리할 수 없다고 알려져 있거나 의심되는 경우, HTTP/1.1 요청에 대해 HTTP/1.0 응답을 보낼 수 있다. 예를 들어 클라이언트가 버전 번호를 올바르게 구문 분석하지 못하거나 중계자가 주어진 마이너 버전과 일치하지 않더라도 HTTP-version을 무작정 전달하는 것으로 알려진 경우이다. 이러한 프로토콜 다운그레이드는 특정 클라이언트 속성(예: User-Agent와 같이 잘못된 클라이언트가 보내는 값과 고유하게 일치하는 요청 헤더 필드)이 트리거되지 않는 한 수행해서는 안 된다.

method 토큰은 대상 리소스에 대해 수행할 요청 메서드를 나타낸다. 요청 메서드는 대소문자를 구분한다.

  method         = token

이 명세서에서 정의한 요청 메서드는 Section 9 of [HTTP]에서 찾을 수 있으며, HTTP 메서드 레지스트리 및 새로운 메서드 정의에 대한 고려사항도 그곳에 설명되어 있다.

request-target은 요청을 적용할 대상 리소스를 식별한다. 클라이언트는 원하는 대상 URI로부터 request-target을 유도한다. method 및 요청이 프록시로 향하는지 여부에 따라 request-target에는 네 가지 서로 다른 형식이 있다.

  request-target = origin-form
                 / absolute-form
                 / authority-form
                 / asterisk-form

request-target에는 공백이 허용되지 않는다. 불행히도 일부 사용자 에이전트는 하이퍼텍스트 참조에서 발견된 공백을 적절히 인코딩하거나 제외하지 못하여, 잘못 형성된 request-line에서 이러한 허용되지 않는 문자가 request-target으로 전송되는 경우가 있다.

잘못된 request-line을 수신한 수신자는 request-target이 적절히 인코딩된 301 (Moved Permanently) 리다이렉트 또는 400 (Bad Request) 오류로 응답하는 것이 SHOULD 권장된다. 수신자는 자동으로 수정하여 리다이렉트 없이 요청을 처리하려고 시도해서는 안 되며, 그 이유는 잘못된 request-line이 요청 체인상의 보안 필터를 우회하기 위해 의도적으로 조작되었을 수 있기 때문이다.

클라이언트는 모든 HTTP/1.1 요청 메시지에서 Host 헤더 필드를 MUST 전송해야 한다(Section 7.2 of [HTTP] 참조). 대상 URI에 authority 구성 요소가 포함되어 있으면, 클라이언트는 userinfo 하위 구성 요소 및 그 "@" 구분자를 제외한 그 authority 구성 요소와 동일한 Host 필드 값을 전송해야 한다. 대상 URI에 authority 구성 요소가 없거나 정의되지 않은 경우, 클라이언트는 빈 필드 값을 가진 Host 헤더 필드를 전송해야 한다.

서버는 Host 헤더 필드가 없거나 Host 헤더 필드가 둘 이상 포함되어 있거나 Host 헤더 필드 값이 유효하지 않은 모든 HTTP/1.1 요청 메시지에 대해 MUST 400 (Bad Request) 상태 코드를 응답해야 한다.

request-target이 absolute-form일 때 대상 URI는 그 request-target이다. 이 경우 서버는 추가 평가를 위해 URI를 일반 구성 요소로 구문 분석한다.

• 서버 구성에서 고정된 URI 스킴을 제공하거나 신뢰할 수 있는 아웃바운드 게이트웨이가 스킴을 제공하면 해당 스킴을 대상 URI에 사용한다. 이는 게이트웨이 서버가 클라이언트의 연결 컨텍스트를 수신하고 이를 자체 연결로 대체하여 인바운드 서버로 전달하기 때문에 대규모 배포에서 일반적이다. 그렇지 않으면 요청이 보안 연결을 통해 수신된 경우 대상 URI의 스킴은 "https"이고, 그렇지 않으면 스킴은 "http"이다.
• request-target이 authority-form인 경우 대상 URI의 authority 구성 요소는 request-target이다. 그렇지 않으면 대상 URI의 authority 구성 요소는 Host 헤더 필드의 필드 값이다. Host 헤더 필드가 없거나 그 값이 비어 있거나 유효하지 않으면 대상 URI의 authority 구성 요소는 비어 있다.
• request-target이 authority-form 또는 asterisk-form인 경우 대상 URI의 결합된 path 및 query 구성 요소는 비어 있다. 그렇지 않으면 대상 URI의 결합된 path 및 query 구성 요소는 request-target이다.
• 위에서 결정된대로 재구성된 대상 URI의 구성 요소는 스킴, "://", authority, 그리고 결합된 경로 및 쿼리 구성 요소를 연결하여 absolute-URI 형태로 다시 결합할 수 있다.

예 1: 다음 메시지가 보안 연결을 통해 수신된 경우

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org

대상 URI는 다음과 같다

https://www.example.org/pub/WWW/TheProject.html

예 2: 다음 메시지가 비보안 연결을 통해 수신된 경우

OPTIONS * HTTP/1.1
Host: www.example.org:8080

대상 URI는 다음과 같다

http://www.example.org:8080

대상 URI의 authority 구성 요소가 비어 있고 그 URI 스킴이 비어 있지 않은 authority를 요구하는 경우(예: "http" 및 "https"), 서버는 요청을 거부하거나 들어오는 연결 컨텍스트와 일치하는 구성된 기본값이 적용되는지 판단할 수 있다. 컨텍스트에는 주소 및 포트, 적용된 보안, 그리고 해당 서버의 구성에 특정한 로컬 정의 정보와 같은 연결 세부사항이 포함될 수 있다. 빈 authority는 추가 처리 전에 구성된 기본값으로 대체된다.

보안 연결 컨텍스트 내에서 authority에 대한 기본 이름을 제공하는 것은 클라이언트가 의도한 authority가 기본값과 다를 가능성이 있는 경우 본질적으로 안전하지 않다. 요청 컨텍스트로부터 고유하게 authority를 식별할 수 있는 서버는 그 식별자를 기본값으로 사용할 수 있다(MAY). 또는 새 클라이언트를 얻는 방법을 설명하는 안전한 리소스로 요청을 리다이렉트하는 것이 더 낫다.

클라이언트의 대상 URI를 재구성하는 것은 대상 리소스 식별 프로세스의 절반에 불과하다는 점에 유의하라. 나머지 절반은 해당 대상 URI가 서버가 응답을 보낼 의사와 능력이 있는 리소스를 식별하는지 여부를 결정하는 것이다(자세한 내용은 Section 7.4 of [HTTP] 참조).

메시지는 개별 필드 이름과 무관한 일반 알고리즘을 사용하여 구문 분석된다. 주어진 필드 행 값 내부의 내용은 메시지 해석의 이후 단계(대개 메시지의 전체 필드 섹션이 처리된 후)에 구문 분석된다.

필드 이름과 콜론 사이에는 공백이 허용되지 않는다. 과거에 이러한 공백 처리의 차이는 요청 라우팅 및 응답 처리에서 보안 취약점을 초래한 바 있다. 서버는 필드 이름과 콜론 사이에 공백이 포함된 수신된 요청 메시지를 MUST 400 (Bad Request) 상태 코드로 거부해야 한다. 프록시는 응답 메시지를 하류로 전달하기 전에 그러한 공백을 제거해야 한다(MUST).

필드 행 값은 선택적 공백(OWS)에 의해 앞뒤로 둘러싸일 수 있다; 일관된 가독성을 위해 필드 행 값 앞에 단일 SP를 두는 것이 바람직하다. 필드 행 값은 그 선행 또는 후행 공백을 포함하지 않는다: 필드 행 값의 첫 번째 비공백 옥텟 앞에 나타나는 OWS 또는 마지막 비공백 옥텟 뒤에 나타나는 OWS는 필드 행에서 필드 행 값을 추출할 때 파서에 의해 제외된다.

역사적으로 HTTP/1.x 필드 값은 각 추가 행 앞에 적어도 하나의 공백 또는 수평 탭(obs-fold)을 추가함으로써 여러 행에 걸쳐 확장될 수 있었다. 이 명세서는 "message/http" 미디어 타입(Section 10.1) 내를 제외하고 그러한 행 접기를 사용 중단(deprecate)한다.

  obs-fold     = OWS CRLF RWS
               ; obsolete line folding

송신자는 메시지에 행 접기(obs-fold)를 포함시키지 않아야 한다(MUST NOT), 즉 필드 행 값이 obs-fold 규칙에 일치하는 경우를 포함하지 않아야 한다. 단, 메시지가 "message/http" 미디어 타입으로 포장되는 경우는 예외이다.

"message/http" 컨테이너 내에 있지 않은 요청 메시지에서 obs-fold를 수신한 서버는 그 메시지를 거부하고 400 (Bad Request)을 보내거나, 바람직하게는 구식 행 접기가 허용되지 않음을 설명하는 표현과 함께 응답하거나, 수신된 각 obs-fold를 필드 값 해석 또는 하류 전달 전에 하나 이상의 SP 옥텟으로 대체해야 한다(MUST).

"message/http" 컨테이너 내에 있지 않은 응답 메시지에서 obs-fold를 수신한 프록시 또는 게이트웨이는 메시지를 폐기하고 502 (Bad Gateway) 응답으로 대체하거나, 바람직하게는 수신된 부적절한 행 접기가 수신되었음을 설명하는 표현과 함께, 수신된 각 obs-fold를 필드 값 해석 또는 하류 전달 전에 하나 이상의 SP 옥텟으로 대체해야 한다(MUST).

"message/http" 컨테이너 내에 있지 않은 응답 메시지에서 obs-fold를 수신한 사용자 에이전트는 필드 값을 해석하기 전에 수신된 각 obs-fold를 하나 이상의 SP 옥텟으로 대체해야 한다(MUST).

The Transfer-Encoding header field는 메시지 본문을 형성하기 위해 콘텐츠에 적용되었거나 적용될 전송 코딩들의 순서에 해당하는 전송 코딩 이름들을 나열한다. 전송 코딩은 섹션 7에 정의되어 있다.

  Transfer-Encoding = #transfer-coding
                       ; defined in [HTTP], Section 10.1.4

Transfer-Encoding은 MIME의 Content-Transfer-Encoding 필드와 유사한 역할을 한다. MIME에서는 7비트 전송 서비스를 통한 이진 데이터의 안전한 전송을 위해 설계되었다( [RFC2045], 섹션 6 ). 그러나 8bit-클린 전송 프로토콜에서는 안전 전송의 초점이 다르다. HTTP의 경우 Transfer-Encoding은 주로 동적으로 생성된 콘텐츠를 정확하게 구분하는 데 사용된다. 또한 전송 중에만 적용되는 인코딩과 선택된 표현의 특성인 인코딩을 구별하는 역할도 한다.

수신자는 청크 전송 코딩( 섹션 7.1 )을 파싱할 수 있어야 한다. 이는 콘텐츠 크기를 미리 알 수 없을 때 메시지 프레이밍에서 중요한 역할을 하기 때문이다. 송신자는 메시지 본문에 대해 청크 전송 코딩을 여러 번 적용해서는 안 된다(즉, 이미 청크된 메시지를 다시 청크하는 것은 허용되지 않는다). 요청의 콘텐츠에 대해 청크 이외의 전송 코딩이 적용된 경우, 송신자는 메시지가 적절히 프레이밍되도록 청크를 최종 전송 코딩으로 적용해야 한다. 응답의 콘텐츠에 대해 청크 이외의 전송 코딩이 적용된 경우, 송신자는 청크를 최종 전송 코딩으로 적용하거나 연결을 닫아 메시지를 종료해야 한다.

예를 들면,

Transfer-Encoding: gzip, chunked

는 콘텐츠가 gzip으로 압축된 다음 chunked 코딩으로 청크되어 메시지 본문을 형성했음을 나타낸다.

Content-Encoding( 섹션 8.4.1 of [HTTP] )과 달리, Transfer-Encoding은 표현의 특성이 아니라 메시지의 속성이다. 요청/응답 체인상의 수신자는 받은 전송 코딩을 디코드하거나 메시지 본문에 추가 전송 코딩을 적용할 수 있으며, 그 경우 Transfer-Encoding 필드 값도 적절히 변경해야 한다. 인코딩 매개변수에 대한 추가 정보는 이 명세서에서 정의하지 않은 다른 헤더 필드들을 통해 제공될 수 있다.

Transfer-Encoding은 메시지 본문을 포함하지 않는 HEAD 요청에 대한 응답이나 GET 요청에 대한 304 (Not Modified) 응답( 섹션 15.4.5 of [HTTP] )에서 보낼 수 있다. 이는 원본 서버가 조건 없는 GET이었더라면 메시지 본문에 전송 코딩을 적용했을 것임을 나타내기 위한 것이다. 그러나 이 표시는 필수는 아니다. 응답 체인상의 어떤 수신자(원본 서버 포함)도 필요하지 않은 경우 전송 코딩을 제거할 수 있다.

서버는 상태 코드가 1xx (Informational) 또는 204 (No Content)인 응답에는 Transfer-Encoding 헤더 필드를 보내면 안 된다. 또한 서버는 CONNECT 요청에 대한 2xx (Successful) 응답에는 Transfer-Encoding 헤더 필드를 보내면 안 된다.

서버가 이해하지 못하는 전송 코딩을 포함한 요청 메시지를 수신하면 SHOULD 501 (Not Implemented)로 응답하는 것이 바람직하다.

Transfer-Encoding은 HTTP/1.1에 추가되었다. 보통 HTTP/1.0만 지원한다고 광고하는 구현체는 전송 인코딩된 콘텐츠를 처리하지 못할 것으로 가정되며, Transfer-Encoding을 포함한 HTTP/1.0 메시지가 수신되면 청크 전송 코딩을 제대로 처리하지 못한 채 전달되었을 가능성이 있다.

클라이언트는 서버가 HTTP/1.1(또는 이후 마이너 버전)을 처리할 것임을 알지 못하는 한 Transfer-Encoding을 포함한 요청을 보내면 안 된다(MUST NOT). 이러한 지식은 명시적 사용자 구성이나 이전에 수신한 응답의 버전을 기억하는 형태일 수 있다. 서버 역시 해당 요청이 HTTP/1.1(또는 이후 마이너 버전)을 지시하지 않는 한 Transfer-Encoding을 포함한 응답을 보내면 안 된다(MUST NOT).

초기 Transfer-Encoding 구현은 메시지 프레이밍을 위한 청크 전송 코딩과 진행 표시줄을 위한 추정 Content-Length 헤더 필드를 함께 보내는 경우가 있었다. 이 때문에 Transfer-Encoding은 Content-Length를 무시하도록 정의되었으며, 상호 배타적이지 않다. 그러나 이러한 메시지를 전달하면 요청 스머글링( 섹션 11.2 ) 또는 응답 분할( 섹션 11.1 ) 공격에 취약해질 수 있으며, 특히 하류 수신자가 이 명세에 따라 메시지를 파싱하지 못하고 HTTP/1.0만 구현하는 경우 문제가 된다.

서버는 Content-Length와 Transfer-Encoding을 모두 포함한 요청을 거부하거나 Transfer-Encoding만을 기준으로 처리할 수 있다(MAY). 그럼에도 불구하고, 서버는 그러한 요청에 응답한 후 잠재적 공격을 피하기 위해 연결을 닫아야 한다(MUST).

HTTP/1.0 메시지에서 Transfer-Encoding 헤더 필드를 수신한 서버 또는 클라이언트는 메시지의 프레이밍이 잘못된 것으로 간주해야 하며(설사 Content-Length가 있어도), 메시지를 처리한 후 연결을 닫아야 한다(MUST). 송신자가 일부 메시지를 버퍼에 보유하고 있을 수 있어, 연결을 계속 사용할 경우 그 잔여가 오해를 불러일으킬 수 있기 때문이다.

메시지에 Transfer-Encoding 헤더 필드가 없을 때, Content-Length 헤더 필드는 잠재적 콘텐츠의 예상 크기를 10진수 옥텟 수로 제공할 수 있다. 콘텐츠를 포함하는 메시지의 경우 Content-Length 필드 값은 데이터(및 메시지)가 끝나는 위치를 결정하는 데 필요한 프레이밍 정보를 제공한다. 콘텐츠를 포함하지 않는 메시지의 경우 Content-Length는 선택된 표현의 크기를 나타낸다.

송신자는 Transfer-Encoding 헤더 필드가 있는 어떤 메시지에서도 Content-Length 헤더 필드를 보내면 안 된다(MUST NOT).

1. HEAD 요청에 대한 모든 응답과 상태 코드가 1xx (Informational), 204 (No Content), 또는 304 (Not Modified)인 모든 응답은 헤더 필드 이후의 첫 번째 빈 줄에 의해 항상 종료되므로, 메시지 본문이나 트레일러 섹션을 포함할 수 없다.

2. CONNECT 요청에 대한 2xx (Successful) 응답은 빈 줄로 헤더 필드가 종료된 직후 연결이 즉시 터널이 됨을 의미한다. 클라이언트는 이러한 메시지에서 수신된 어떤 Content-Length 또는 Transfer-Encoding 헤더 필드도 무시해야 한다(MUST).

3. 메시지가 Transfer-Encoding과 Content-Length를 모두 포함하여 수신된 경우, Transfer-Encoding이 Content-Length를 무시한다. 이러한 메시지는 요청 스머글링( 섹션 11.2 ) 또는 응답 분할( 섹션 11.1 )을 시도하려는 것으로 보일 수 있으며 오류로 처리되어야 한다. 중계자가 메시지를 전달하기로 선택하는 경우, 전달하기 전에 수신된 Content-Length 필드를 먼저 제거하고 Transfer-Encoding을 처리해야 한다(MUST).

4. Transfer-Encoding 헤더 필드가 존재하고 마지막 인코딩이 청크 전송 코딩( 섹션 7.1 )인 경우, 메시지 본문 길이는 청크된 데이터를 읽고 디코딩하여 전송 코딩이 데이터가 완전함을 나타낼 때까지 판정된다.

   Transfer-Encoding 헤더 필드가 응답에 존재하고 청크가 최종 인코딩이 아닌 경우, 메시지 본문 길이는 서버가 연결을 닫을 때까지 연결을 읽음으로써 결정된다.

   Transfer-Encoding 헤더 필드가 요청에 존재하고 청크가 최종 인코딩이 아닌 경우, 메시지 본문 길이는 신뢰할 수 있게 결정할 수 없으므로 서버는 400 (Bad Request)로 응답한 다음 연결을 닫아야 한다(MUST).

5. Transfer-Encoding이 없고 잘못된 Content-Length 헤더 필드가 있는 메시지가 수신되면, 메시지 프레이밍은 잘못된 것이며 수신자는 이를 복구 불가능한 오류로 처리해야 한다(MUST), 단 필드 값이 쉼표로 구분된 목록으로 성공적으로 파싱될 수 있고( 섹션 5.6.1 of [HTTP] ), 목록의 모든 값이 유효하며 목록의 모든 값이 동일한 경우(이 경우 메시지는 해당 단일 값을 Content-Length 필드 값으로 사용하여 처리된다). 요청 메시지에서 복구 불가능한 오류가 발생하면 서버는 400 (Bad Request)로 응답한 뒤 연결을 닫아야 한다. 프록시가 응답 메시지에서 이 오류를 수신하면 프록시는 서버와의 연결을 닫고 수신된 응답을 폐기한 뒤 클라이언트에 502 (Bad Gateway) 응답을 보내야 한다. 사용자 에이전트가 응답 메시지에서 이 오류를 수신하면 사용자 에이전트는 서버와의 연결을 닫고 수신된 응답을 폐기해야 한다.

6. Content-Length 헤더 필드가 유효하게 존재하고 Transfer-Encoding이 없는 경우, 그 10진 값은 예상되는 메시지 본문 길이를 옥텟 단위로 정의한다. 송신자가 표시된 옥텟 수를 모두 전송하기 전에 연결을 닫거나 수신자가 타임아웃이 발생하면, 수신자는 메시지가 불완전하다고 간주하고 연결을 닫아야 한다(MUST).

7. 이것이 요청 메시지이고 위의 어떤 경우도 해당되지 않으면, 메시지 본문 길이는 0이다(메시지 본문이 존재하지 않음).

8. 그렇지 않으면, 선언된 메시지 본문 길이가 없는 응답 메시지이므로 메시지 본문 길이는 서버가 연결을 닫기 전에 수신한 옥텟 수에 의해 결정된다.

완전히 수신된 닫기-구분된 응답 메시지와 네트워크 장애로 인해 부분적으로 수신된 메시지를 구분할 방법이 없으므로, 서버는 가능한 경우 인코딩 또는 길이로 구분되는 메시지를 생성하는 것이 바람직하다(SHOULD). 닫기-구분 기능은 주로 HTTP/1.0과의 하위 호환성을 위해 존재한다.

서버는 메시지 본문이 있지만 Content-Length가 없는 요청을 411 (Length Required)로 응답하여 거부할 수 있다(MAY).

청크 이외의 전송 코딩이 적용되지 않은 한, 메시지 본문 길이를 미리 알 수 있는 경우 요청을 보내는 클라이언트는 청크 전송 코딩 대신 유효한 Content-Length 헤더 필드를 사용하는 것이 권장된다(SHOULD)—일부 기존 서비스는 청크 전송 코딩을 이해하더라도 청크에 대해 411 (Length Required)로 응답하기 때문이다. 이는 일반적으로 그러한 서비스들이 게이트웨이를 통해 구현되어 전체 요청을 버퍼링하기 전에 콘텐츠 길이를 요구하기 때문이다.

메시지 본문을 포함한 요청을 전송하는 사용자 에이전트는 유효한 Content-Length 헤더 필드 또는 청크 전송 코딩 중 하나를 반드시 전송해야 한다(MUST). 클라이언트는 서버가 HTTP/1.1(또는 이후)을 처리할 것임을 알지 못하는 한 청크 전송 코딩을 사용해서는 안 된다(MUST NOT).

연결의 마지막 요청에 대한 최종 응답이 완전히 수신되었는데도 읽을 추가 데이터가 남아 있으면, 사용자 에이전트는 남은 데이터를 폐기하거나 그 데이터가 이전 메시지 본문의 일부인지 판단을 시도할 수 있다. 이는 이전 메시지의 Content-Length 값이 잘못된 경우에 해당할 수 있다. 클라이언트는 그러한 추가 데이터를 별도의 응답으로 처리, 캐시 또는 전달하면 안 된다(MUST NOT)—그렇게 하면 캐시 오염에 취약해지기 때문이다.

청크 전송 코딩은 콘텐츠를 일련의 청크로 래핑하여 각각의 크기 표시자를 갖게 하고, 선택적인 트레일러 섹션을 뒤따르게 한다. 청크는 알려지지 않은 크기의 콘텐츠 스트림을 길이-구분된 버퍼의 연속으로 전송할 수 있게 하여 송신자가 연결을 유지하고 수신자가 전체 메시지를 수신했는지를 알 수 있게 한다.

  chunked-body   = *chunk
                   last-chunk
                   trailer-section
                   CRLF

  chunk          = chunk-size [ chunk-ext ] CRLF
                   chunk-data CRLF
  chunk-size     = 1*HEXDIG
  last-chunk     = 1*("0") [ chunk-ext ] CRLF

  chunk-data     = 1*OCTET ; a sequence of chunk-size octets

chunk-size 필드는 청크 데이터의 옥텟 수를 나타내는 16진수 숫자의 문자열이다. chunk-size가 0인 청크를 수신하면 청크 전송 코딩은 완료되며, 선택적으로 트레일러 섹션이 뒤따르고 마지막으로 빈 줄로 종료된다.

수신자는 청크 전송 코딩을 파싱하고 디코드할 수 있어야 한다(MUST).

HTTP/1.1은 중계자가 전체 응답을 버퍼링할 수 있음을 보장할 수 있도록 청크된 응답의 크기를 제한하는 수단을 정의하지 않는다. 또한 매우 큰 청크 크기는 수신 구현에서 정수 변환 오버플로우 또는 정수 표현의 정밀도 손실을 초래할 수 있다. 따라서 수신자는 잠재적으로 큰 16진 숫자를 예상하고 정수 변환 오버플로우나 정밀도 손실로 인한 구문 오류를 방지해야 한다(MUST).

청크 코딩은 어떠한 매개변수도 정의하지 않는다. 매개변수가 존재하면 오류로 간주하는 것이 바람직하다(SHOULD).

compress (and x-compress)

자세한 내용은 섹션 8.4.1.1 참조.

deflate

자세한 내용은 섹션 8.4.1.2 참조.

gzip (and x-gzip)

자세한 내용은 섹션 8.4.1.3 참조.

압축 코딩들은 어떠한 매개변수도 정의하지 않는다. 이들 압축 코딩에 매개변수가 있는 경우 오류로 처리하는 것이 바람직하다(SHOULD).

"HTTP Transfer Coding Registry"는 전송 코딩 이름의 네임스페이스를 정의한다. 이는 https://www.iana.org/assignments/http-parameters에서 유지 관리된다.

• Name
• Description
• Pointer to specification text

전송 코딩의 이름은 인코딩 변환이 동일하지 않는 한 콘텐츠 코딩의 이름과 중복되어서는 안 된다(이는 섹션 7.2에서 정의한 압축 코딩의 경우처럼 인코딩 변환이 동일한 경우는 예외이다).

TE 헤더 필드는 여러 전송 코딩이 허용될 때 우선순위 값을 나타내기 위해 "q"라는 의사-매개변수를 사용한다. 향후 전송 코딩 등록은 모호함을 피하기 위해 대소문자 구분 없이 "q"라는 이름의 매개변수를 정의해서는 안 된다(SHOULD NOT).

이 네임스페이스에 값을 추가하려면 IETF 검토가 필요하며(자세한 내용은 섹션 4.8 참조) 등록은 이 명세서에서 정의한 전송 코딩의 목적에 부합해야 한다(MUST).

인코딩 형식의 식별에 프로그램 이름을 사용하는 것은 바람직하지 않으며 향후 인코딩에서는 권장되지 않는다.

TE 필드( 섹션 10.1.4 of [HTTP] )는 클라이언트가 응답에서 chunked 이외에 어떤 전송 코딩을 허용하는지와 클라이언트가 청크 전송 코딩에서 트레일러 필드를 보존할 의사가 있는지를 나타내는 데 사용된다.

클라이언트는 TE에 chunked 전송 코딩 이름을 보내면 안 된다(MUST NOT); chunked는 HTTP/1.1 수신자에게 항상 허용된다.

TE 사용의 세 가지 예시는 아래와 같다.

TE: deflate
TE:
TE: trailers, deflate;q=0.5

여러 전송 코딩이 허용될 때, 클라이언트는 선호도에 따라 소문자 구분 없이 "q" 매개변수를 사용하여 코딩의 순위를 지정할 수 있다(콘텐츠 협상 필드에서 사용하는 q값과 유사함). 순위 값은 0에서 1 범위의 실수이며, 0.001은 가장 덜 선호되고 1은 가장 선호된다; 0은 "허용되지 않음"을 뜻한다.

TE 필드 값이 비어 있거나 TE 필드가 없는 경우, 허용되는 유일한 전송 코딩은 chunked이다. 전송 코딩이 없는 메시지는 항상 허용된다.

키워드 "trailers"는 송신자가 트레일러 필드를 폐기하지 않음을 나타낸다(자세한 내용은 섹션 6.5 참조).

TE 헤더 필드는 즉시 연결에만 적용되므로, TE를 보내는 송신자는 TE 헤더 필드가 중계자에 의해 전달되는 것을 방지하기 위해 Connection 헤더 필드 내에 "TE" 연결 옵션도 함께 보내야 한다(MUST).

다양한 전송층 또는 세션층 프로토콜을 통해 연결이 어떻게 설정되는지를 설명하는 것은 이 명세서의 범위를 벗어난다. 각 HTTP 연결은 하나의 기저 전송 연결에 매핑된다.

HTTP/1.1은 특정 요청 메시지와 그에 대응하는 하나 이상의 응답 메시지를 연결하기 위한 요청 식별자를 포함하지 않는다. 따라서 같은 연결에서 요청이 이루어진 순서와 응답이 도착하는 순서는 정확히 일치해야 한다고 가정한다. 하나의 요청에 대해 여러 응답이 발생하는 경우는 하나 이상의 정보 응답(1xx)이 최종 응답에 앞서 보내질 때만 발생한다.

한 연결에서 미완료 요청이 여러 개인 클라이언트는 전송한 순서대로 미완료 요청 목록을 유지해야 하며(MUST), 해당 연결에서 수신한 각 응답 메시지를 아직 최종(비-1xx) 응답을 받지 못한 첫 번째 미완료 요청에 연관시켜야 한다(MUST).

클라이언트가 미완료 요청이 없는 연결에서 데이터를 수신하면, 그 데이터는 유효한 응답으로 간주해서는 안 된다(MUST NOT). 메시지 구분이 모호해졌으므로 클라이언트는 연결을 닫는 것이 바람직하다(SHOULD), 단 수신된 데이터가 하나 이상의 CRLF만으로 구성되어 폐기할 수 있는 경우(Section 2.2 참조)를 제외한다.

HTTP/1.1은 다중 요청 및 응답을 단일 연결에서 전송할 수 있는 지속 연결의 사용을 기본값으로 한다. HTTP 구현체는 지속 연결을 지원하는 것이 바람직하다(SHOULD).

• 연결 옵션으로 "close"가 존재하면(Section 9.6) 현재 응답 후 연결은 지속되지 않는다; 그렇지 않으면,
• 수신된 프로토콜이 HTTP/1.1(또는 이후)인 경우 현재 응답 후 연결은 지속된다; 그렇지 않으면,
• 수신된 프로토콜이 HTTP/1.0이고 "keep-alive" 연결 옵션이 존재하며 수신자가 프록시가 아니거나 메시지가 응답이며 수신자가 HTTP/1.0 "keep-alive" 메커니즘을 존중하려는 경우 현재 응답 후 연결은 지속된다; 그렇지 않으면,
• 현재 응답 후 연결은 닫힌다.

지속 연결을 지원하지 않는 클라이언트는 모든 요청 메시지에서 "close" 연결 옵션을 전송해야 한다(MUST).

지속 연결을 지원하지 않는 서버는 상태 코드가 1xx (Informational)가 아닌 모든 응답 메시지에서 "close" 연결 옵션을 전송해야 한다(MUST).

클라이언트는 "close" 연결 옵션을 전송하거나 HTTP/1.0 응답에서 "keep-alive" 연결 옵션을 수신할 때까지 지속 연결에서 추가 요청을 보낼 수 있다(MAY).

연결을 지속하려면 연결의 모든 메시지는 스스로 정의된 메시지 길이(즉, 연결 종료로 정의되지 않는 길이)를 가져야 한다(자세한 내용은 Section 6 참조). 서버는 전체 요청 메시지 본문을 읽거나 응답을 전송한 후 연결을 닫아야 한다(MUST); 그렇지 않으면 지속 연결에 남아 있는 데이터는 다음 요청으로 잘못 해석될 수 있다. 마찬가지로, 클라이언트는 동일한 연결을 재사용하려면 전체 응답 메시지 본문을 읽어야 한다(MUST).

프록시 서버는 HTTP/1.0 클라이언트와 지속 연결을 유지해서는 안 된다(MUST NOT). 자세한 내용은 Appendix C.2.2 참조.

HTTP/1.0 클라이언트와의 하위 호환성에 대한 추가 정보는 Appendix C.2.2를 참조하라.

클라이언트는 특정 서버에 대해 동시에 열어 두는 연결 수를 제한하는 것이 바람직하다.

이전 HTTP 개정판은 연결 수의 상한을 명시했지만, 이는 많은 응용 프로그램에 비현실적임이 밝혀졌다. 따라서 이 명세서는 특정 최대 연결 수를 강제하지 않고, 대신 클라이언트가 여러 연결을 열 때 보수적일 것을 권장한다.

여러 연결을 사용하는 주된 이유는 서버 측 처리 시간이 많이 걸리거나 매우 큰 콘텐츠 전송이 다음 요청을 블록하는 "헤드 오브 라인 블로킹" 문제를 피하기 위함이다. 그러나 각 연결은 서버 자원을 소비한다.

또한 여러 연결을 사용하면 혼잡한 네트워크에서 바람직하지 않은 부작용을 초래할 수 있다. 더 많은 연결을 사용하면 초기의 동기화된 전송 동작으로 인해 혼잡이 발생할 수 있어, 적은 병렬 연결을 사용했을 때와 다른 결과를 초래할 수 있다.

서버는 단일 클라이언트로부터의 과도한 연결 수와 같이 남용 또는 DoS 공격의 특징으로 판단되는 트래픽을 거부할 수 있다는 점을 유의하라.

서버는 비활성 연결을 더 이상 유지하지 않는 시간 초과 값을 보통 가지고 있다. 프록시 서버는 클라이언트가 동일한 프록시를 통해 더 많은 연결을 만들 가능성이 있으므로 이 값을 더 높게 설정할 수 있다. 지속 연결의 사용은 클라이언트나 서버 어느 쪽에도 이 타임아웃의 길이(또는 존재)에 대한 요구사항을 부과하지 않는다.

타임아웃을 적용하려는 클라이언트 또는 서버는 연결에 대해 정상 종료(graceful close)를 수행하는 것이 바람직하다(SHOULD). 구현체는 열린 연결에서 수신된 종료 신호를 지속적으로 모니터링하고 적절히 응답해야 한다(SHOULD), 왜냐하면 양측의 신속한 종료는 할당된 시스템 자원을 회수하는 데 도움이 되기 때문이다.

클라이언트, 서버 또는 프록시는 언제든지 전송 연결을 닫을 MAY 있다. 예를 들어, 클라이언트가 새 요청 전송을 시작한 동시에 서버가 "유휴" 연결을 닫기로 결정할 수 있다. 서버 관점에서는 연결이 유휴 상태에서 닫히는 것이지만, 클라이언트 관점에서는 요청이 진행 중일 수 있다.

서버는 가능한 경우 지속 연결을 유지하고 기저 전송의 흐름 제어 메커니즘이 일시적인 과부하를 해결하도록 허용하는 것이 바람직하다(SHOULD). 연결을 종료하고 클라이언트가 재시도하도록 기대하는 방식은 네트워크 혼잡이나 서버 부하를 악화시킬 수 있다.

메시지 본문을 전송하는 클라이언트는 전송 중에 네트워크 연결에서 오류 응답이 오는지 모니터링해야 한다(SHOULD). 클라이언트가 서버가 메시지 본문을 수신하기를 원하지 않으며 연결을 닫고 있다는 응답을 보면 즉시 전송을 중단하고 자신의 쪽 연결을 닫아야 한다(SHOULD).

"close" 연결 옵션은 송신자가 응답 완료 후 이 연결을 닫을 것이라는 신호로 정의된다. 송신자는 연결을 닫을 의사가 있을 때 "close" 연결 옵션을 포함하는 Connection 헤더 필드를 전송하는 것이 바람직하다(SHOULD). 예를 들어,

Connection: close

요청 헤더 필드로서 이는 클라이언트가 이 연결에서 보낼 마지막 요청임을 나타내고, 응답에서는 동일한 필드가 서버가 응답 메시지 완료 후 이 연결을 닫을 것임을 나타낸다.

필드 이름 "Close"는 예약되어 있으므로, 해당 이름을 헤더 필드로 사용하는 것은 "close" 연결 옵션과 충돌할 수 있다.

"close" 연결 옵션을 전송한 클라이언트는 그 요청(해당 "close"를 포함한 것) 이후로 해당 연결에서 추가 요청을 보내서는 안 되며(MUST NOT) 이 요청에 대한 최종 응답을 읽은 후 연결을 닫아야 한다(MUST).

"close" 연결 옵션을 수신한 서버는 그 "close"를 포함한 요청에 대한 최종 응답을 전송한 후 연결 종료를 시작해야 한다(MUST; 아래 참조). 서버는 해당 연결에서 최종 응답으로 "close" 연결 옵션을 보내는 것이 바람직하다(SHOULD). 서버는 해당 연결에서 수신되는 추가 요청을 처리해서는 안 된다(MUST NOT).

"close" 연결 옵션을 보내는 서버는 그 "close"를 포함한 응답을 전송한 후 연결 종료를 시작해야 하며(MUST) 해당 연결에서 수신되는 추가 요청을 처리해서는 안 된다(MUST NOT).

"close" 연결 옵션을 포함하는 응답을 수신한 클라이언트는 해당 연결에서의 요청 전송을 중단하고 그 응답을 읽은 후 연결을 닫아야 하며(MUST) 추가로 파이프라인된 요청이 있으면 서버가 그것들을 처리할 것이라고 가정해서는 안 된다(SHOULD NOT).

서버가 TCP 연결을 즉시 닫는 경우, 클라이언트가 마지막 HTTP 응답을 읽지 못할 위험이 상당히 있다. 서버가 클라이언트로부터 추가 데이터를 수신하면(예: 서버의 응답을 받기 전에 클라이언트가 보낸 또 다른 요청), 서버의 TCP 스택은 클라이언트로 리셋 패킷을 보낼 것이고; 불행히도 이 리셋 패킷은 클라이언트의 미확인 입력 버퍼를 지워서 클라이언트의 HTTP 파서가 이를 읽고 해석하기 전에 소멸시킬 수 있다.

TCP 리셋 문제를 피하기 위해 서버는 일반적으로 단계적으로 연결을 닫는다. 먼저 서버는 쓰기 측만 닫아 반쪽 닫기(half-close)를 수행한다. 그런 다음 서버는 클라이언트의 해당 닫힘을 수신하거나 서버 자신의 TCP 스택이 서버의 마지막 응답을 포함한 패킷에 대한 클라이언트의 확인을 수신했다고 합리적으로 확신할 때까지 연결을 계속 읽는다. 마지막으로 서버는 연결을 완전히 닫는다.

리셋 문제에 TCP만 해당하는지 또는 다른 전송 프로토콜에서도 발생하는지는 알려져 있지 않다.

클라이언트가 반쪽 닫기로 TCP 연결을 닫는다고 해서 요청 메시지가 구분되거나 클라이언트가 더 이상 응답에 관심이 없다는 것을 의미하지는 않는다. 일반적으로 전송 신호는 HTTP/1.1이 전송과 독립적이므로 에지케이스를 신호하기 위해 신뢰할 수 없다.

개념적으로 HTTP/TLS는 TLS로 보호된 연결을 통해 HTTP 메시지를 전송하는 것이다([TLS13]).

HTTP 클라이언트는 또한 TLS 클라이언트로 동작한다. 적절한 포트로 서버에 연결을 시도하고 TLS 핸드셰이크를 시작하기 위해 TLS ClientHello를 전송한다. TLS 핸드셰이크가 완료되면 클라이언트는 첫 번째 HTTP 요청을 시작할 수 있다. 모든 HTTP 데이터는 TLS의 "application data"로 전송되어야 하며(MUST) 그 외에는 일반 연결처럼 취급된다(지속 연결 재사용 포함).

TLS는 오류가 아닌 연결 종료 전에 종료 알림(closure alerts)을 교환하여 안전한 연결 종료를 제공한다(자세한 내용은 Section 6.1 of [TLS13] 참조). 유효한 종료 알림을 수신하면 구현체는 해당 연결에서 더 이상의 데이터가 수신되지 않음을 확신할 수 있다.

구현체가 자신이 관심 있는 모든 메시지 데이터를 전송하거나 수신했음을 알게 되면, 보통 HTTP 메시지 경계를 감지함으로써, 상대의 대응 종료 알림을 기다리지 않고 종료 알림을 보낸 뒤 연결을 닫아 "incomplete close"를 생성할 수 있다.

불완전한 종료는 이미 수신된 데이터의 보안성을 문제 삼지는 않지만, 이후의 데이터가 잘리었을 가능성을 나타낼 수 있다. TLS는 HTTP 메시지 프레이밍을 직접 알지 못하므로 메시지가 완전한지 판단하려면 HTTP 데이터를 검사해야 한다. 불완전한 메시지 처리 방법은 Section 8에 정의되어 있다.

불완전한 종료를 만났을 때, 클라이언트는 다음 중 어느 하나라도 수신했으면 그 요청들을 완료된 것으로 간주하는 것이 바람직하다(SHOULD):

1. Content-Length 헤더 필드에 지정된 만큼의 데이터

2. 청크 전송 코딩이 사용된 경우의 종료를 알리는 0크기 청크

청크 전송 코딩도 Content-Length도 없는 응답은 유효한 종료 알림을 수신한 경우에만 완전한 것으로 간주된다. 불완전한 메시지를 완전한 것으로 처리하면 구현체를 공격에 노출할 수 있다.

불완전한 종료를 감지한 클라이언트는 우아하게 복구해야 한다(SHOULD).

클라이언트는 연결을 닫기 전에 종료 알림을 반드시 보내야 한다(MUST). 더 이상 데이터를 받지 않을 것으로 예상되는 클라이언트는 서버의 종료 알림을 기다리지 않고 단순히 연결을 닫아 서버 측에서 불완전한 종료를 생성할 MAY 있다.

서버는 클라이언트가 데이터를 끝까지 찾을 수 있는 경우가 많으므로 클라이언트로부터 불완전한 종료를 받을 준비를 해야 한다(SHOULD).

서버는 클라이언트와 종료 알림 교환을 시도해야 하며(MUST) 종료 알림을 보낸 후 연결을 닫아 클라이언트 측에서 불완전한 종료를 생성할 MAY 있다.

"message/http" 미디어 타입은 하나의 HTTP 요청 또는 응답 메시지를 포함하는 데 사용할 수 있으며, 이때 모든 "message" 유형에 적용되는 MIME의 행 길이 및 인코딩 제한을 준수해야 한다. 행 길이 제한 때문에 "message/http" 내의 필드 값은 obs-fold에서 설명한 대로 여러 줄에 걸쳐 필드 값을 전달하기 위해 행 접기(Section 5.2)를 사용할 수 있다. "message/http" 데이터를 수신하는 수신자는 메시지를 처리할 때 모든 구식 행 접기(obs-fold)를 하나 이상의 SP 문자로 대체해야 한다(MUST).

Type name:

message

Subtype name:

http

Required parameters:

N/A

Optional parameters:

version, msgtype

version:

포함된 메시지의 HTTP-version 번호(예: "1.1"). 없으면 본문 첫 줄에서 버전을 판별할 수 있다.

msgtype:

메시지 유형 — "request" 또는 "response". 없으면 본문 첫 줄에서 유형을 판별할 수 있다.

Encoding considerations:

허용되는 값은 "7bit", "8bit", 또는 "binary"뿐이다

Security considerations:

보안 고려사항은 섹션 11을 참조하라

Interoperability considerations:

N/A

Published specification:

RFC 9112 (참조 섹션 10.1).

Applications that use this media type:

N/A

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

추가 정보는 저자 주소(Authors' Addresses) 섹션을 참조하라.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

저자 주소 섹션을 참조하라.

Change controller:

IESG

"application/http" 미디어 타입은 하나 이상의 HTTP 요청 또는 응답 메시지(혼합되지 않음)의 파이프라인을 포함하는 데 사용할 수 있다.

Type name:

application

Subtype name:

http

Required parameters:

N/A

Optional parameters:

version, msgtype

version:

포함된 메시지들의 HTTP-version 번호(예: "1.1"). 없으면 본문 첫 줄에서 버전을 판별할 수 있다.

msgtype:

메시지 유형 — "request" 또는 "response". 없으면 본문 첫 줄에서 유형을 판별할 수 있다.

Encoding considerations:

이 타입으로 둘러싸인 HTTP 메시지는 "binary" 형식이다; 이메일로 전송할 때는 적절한 Content-Transfer-Encoding 사용이 필요하다.

Security considerations:

보안 고려사항은 섹션 11을 참조하라

Interoperability considerations:

N/A

Published specification:

RFC 9112 (참조 섹션 10.2).

Applications that use this media type:

N/A

Fragment identifier considerations:

N/A

Additional information:

Deprecated alias names for this type:

N/A

Magic number(s):

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

추가 정보는 저자 주소(Authors' Addresses) 섹션을 참조하라.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

저자 주소 섹션을 참조하라.

Change controller:

IESG

응답 분할(일명 CRLF 인젝션)은 HTTP 메시지 프레이밍의 행 기반 특성과 지속 연결에서 요청과 응답의 순서 연관을 악용하는 다양한 웹 공격에서 사용되는 일반적인 기법이다([Klein]). 이 기법은 요청이 공유 캐시를 통과할 때 특히 심각한 피해를 줄 수 있다.

응답 분할은 공격자가 요청의 어떤 매개변수에 인코딩된 데이터를 보내고, 그 데이터가 나중에 디코드되어 응답의 헤더 필드 중 하나에 반영되는 서버(보통 애플리케이션 서버)의 취약점을 악용한다. 디코드된 데이터가 응답이 끝나고 이후 응답이 시작된 것처럼 보이도록 조작되면 응답이 분할되고, 분할된 두 번째 응답의 내용은 공격자가 제어하게 된다. 그런 다음 공격자는 동일한 지속 연결에서 다른 요청을 수행하고 수신자(중계자 포함)를 속여 분할된 두 번째 부분이 두 번째 요청에 대한 신뢰할 수 있는 응답이라고 믿게 만들 수 있다.

예를 들어, 요청-타겟 내의 매개변수가 애플리케이션 서버에 의해 읽혀 리다이렉트에 재사용되어 그 매개변수가 응답의 Location 헤더 필드에 반영될 수 있다. 매개변수가 애플리케이션에 의해 디코드되고 응답 필드에 올바르게 인코딩되지 않으면, 공격자는 인코딩된 CRLF 옥텟 및 기타 콘텐츠를 보내어 애플리케이션의 단일 응답을 두 개 이상의 응답처럼 보이게 만들 수 있다.

응답 분할에 대한 일반적인 방어는 인코딩된 CR 및 LF(예: "%0D" 및 "%0A")처럼 보이는 데이터를 필터링하는 것이다. 그러나 이는 애플리케이션 서버가 단지 URI 디코딩만 수행한다는 가정에 기반하며, 문자셋 변환, XML 엔티티 변환, base64 디코딩, sprintf 재포맷 등 더 모호한 데이터 변환이 일어날 수 있는 경우를 고려하지 못한다. 더 효과적인 완화책은 서버의 핵심 프로토콜 라이브러리 이외에서 헤더 섹션 내에 CR 또는 LF를 전송하지 못하도록 제한하는 것으로, 이는 잘못된 옥텟을 필터링하는 API로 헤더 필드 출력을 제한하고 애플리케이션 서버가 프로토콜 스트림에 직접 쓰는 것을 허용하지 않는 것을 의미한다.

요청 스머글링([Linhart])은 서로 다른 수신자들 사이의 프로토콜 파싱 차이를 악용하여 추가 요청을 숨기는 기법으로, 이러한 추가 요청은 정책에 의해 차단되거나 비활성화되었을 수 있는 것을 겉보기에는 무해한 요청 안에 숨긴다. 응답 분할과 마찬가지로 요청 스머글링은 HTTP 사용에 대한 다양한 공격으로 이어질 수 있다.

이 명세서는 특히 메시지 프레이밍과 관련된 요청 파싱에 대해 섹션 6.3에서 요청 스머글링의 효과를 줄이기 위한 새로운 요구사항을 도입했다.

HTTP는 메시지 무결성을 보장하는 특정 메커니즘을 정의하지 않으며, 대신 기저 전송 프로토콜의 오류 검출 능력과 완전성을 감지하기 위한 길이 또는 청크 구분 프레이밍에 의존한다. 역사적으로 단일 무결성 메커니즘의 부재는 대부분의 HTTP 통신이 비공식적이라는 점으로 정당화되었으나, HTTP의 광범위한 사용으로 인해 메시지 무결성 검증이 중요한 환경에서의 사용이 증가하고 있다.

"https" 스킴과 함께 제공되는 메커니즘(예: 인증된 암호화)은 메시지 변조로부터 보호를 제공한다. 다만 연결 종료가 메시지 절단(truncate)에 이용될 수 없도록 주의가 필요하다(자세한 내용은 섹션 9.8 참조). 사용자 에이전트는 불완전한 메시지를 거부하거나 특별하게 처리할 수 있다. 예를 들어 의료 기록 또는 약물 상호작용 정보를 표시하는 브라우저는 프로토콜에 의해 해당 정보가 전송 중 불완전하거나 만료되었거나 손상되었다고 판단되면 사용자에게 이를 표시해야 할 것이다. 이러한 메커니즘은 사용자 에이전트 확장이나 응답에 포함된 메시지 무결성 메타데이터의 존재를 통해 선택적으로 활성화될 수 있다.

"http" 스킴은 우발적이거나 악의적인 메시지 변조로부터 보호를 제공하지 않는다.

프로토콜의 확장은 중계자에 의한 원치 않는 메시지 변조 위험을 완화하는 데 사용될 수 있으며, "https" 스킴이 사용되더라도 중계자에 의한 변조 위험을 줄일 수 있다. 무결성은 메시지 인증 코드 또는 디지털 서명 같은 메커니즘을 확장 가능한 메타데이터 필드로 선택적으로 추가하여 보장할 수 있다.

HTTP는 메시지 기밀성이 필요할 때 이를 제공하기 위해 기저 전송 프로토콜에 의존한다. HTTP는 전송 프로토콜과 독립적으로 설계되어 다양한 형태의 암호화된 연결 위에서 사용할 수 있으며, 그러한 전송 선택은 URI 스킴이나 사용자 에이전트 구성에 의해 식별된다.

기밀 연결이 필요한 리소스를 식별하기 위해 "https" 스킴을 사용할 수 있다(자세한 내용은 섹션 4.2.2 참조).

IANA는 https://www.iana.org/assignments/http-fields에 있는 "Hypertext Transfer Protocol (HTTP) Field Name Registry"에 다음 필드 이름들을 추가했다. 이는 섹션 18.4에 설명된 바와 같다.

IANA는 https://www.iana.org/assignments/media-types의 "Media Types" 레지스트리를 섹션 10.1 및 10.2에 있는 등록 정보로 업데이트했다. 이는 미디어 타입 "message/http" 및 "application/http"에 대한 것이다.

IANA는 https://www.iana.org/assignments/http-parameters/의 "HTTP Transfer Coding Registry"를 섹션 7.3의 등록 절차 및 아래 표에 요약된 콘텐츠 코딩 이름으로 업데이트했다.

13.1. 규범적 참고문헌

[CACHING]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Caching”, STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022.

[HTTP]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022.

[RFC1950]

Deutsch, P. and J-L. Gailly, “ZLIB Compressed Data Format Specification version 3.3”, RFC 1950, DOI 10.17487/RFC1950, May 1996, <https://www.rfc-editor.org/info/rfc1950>.

[RFC1951]

Deutsch, P., “DEFLATE Compressed Data Format Specification version 1.3”, RFC 1951, DOI 10.17487/RFC1951, May 1996, <https://www.rfc-editor.org/info/rfc1951>.

[RFC1952]

Deutsch, P., “GZIP file format specification version 4.3”, RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC7405]

Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.

[RFC8174]

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[TLS13]

Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[URI]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[USASCII]

American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange”, ANSI X3.4, 1986.

[Welch]

Welch, T., “A Technique for High-Performance Data Compression”, IEEE Computer 17(6), DOI 10.1109/MC.1984.1659158, June 1984, <https://ieeexplore.ieee.org/document/1659158/>.

13.2. 참조 문헌(정보성)

[HTTP/1.0]

Berners-Lee, T., Fielding, R., and H. Frystyk, “Hypertext Transfer Protocol -- HTTP/1.0”, RFC 1945, DOI 10.17487/RFC1945, May 1996, <https://www.rfc-editor.org/info/rfc1945>.

[Klein]

Klein, A., “Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics”, March 2004, <https://packetstormsecurity.com/papers/general/whitepaper_httpresponse.pdf>.

[Linhart]

Linhart, C., Klein, A., Heled, R., and S. Orrin, “HTTP Request Smuggling”, June 2005, <https://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf>.

[RFC2045]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.

[RFC2046]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.

[RFC2049]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples”, RFC 2049, DOI 10.17487/RFC2049, November 1996, <https://www.rfc-editor.org/info/rfc2049>.

[RFC2068]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2068, DOI 10.17487/RFC2068, January 1997, <https://www.rfc-editor.org/info/rfc2068>.

[RFC2557]

Palme, J., Hopmann, A., and N. Shelness, “MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)”, RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/info/rfc2557>.

[RFC5322]

Resnick, P., Ed., “Internet Message Format”, RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.

[RFC7230]

Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

HTTP는 MIME 준수 프로토콜은 아니지만, 메시지는 사용된 MIME 프로토콜의 버전을 나타내기 위해 단일 MIME-Version 헤더 필드를 포함할 수 있다. MIME-Version 헤더 필드의 사용은 메시지가 MIME 프로토콜과 완전하게 일치함을 나타낸다([RFC2045] 참조). 송신자는 HTTP 메시지를 엄격한 MIME 환경으로 내보낼 때 가능한 경우 완전한 준수를 보장할 책임이 있다.

MIME은 Internet 메일 본문 부분을 전송 전에 정규형으로 변환할 것을 요구한다(자세한 내용은 Section 4 of [RFC2049] 참조). 또한 "text" 타입의 콘텐츠는 줄 바꿈을 CRLF로 표현해야 하며, 줄 바꿈 이외의 곳에서 CR 또는 LF를 사용하는 것을 금지한다([RFC2046]). 반면 HTTP는 콘텐츠 내에서 CRLF, 단독 CR 또는 단독 LF 중 어느 것을 줄 바꿈으로 사용할지에 대해서는 제한하지 않는다.

HTTP에서 엄격한 MIME 환경으로의 프록시나 게이트웨이는 텍스트 미디어 타입 내의 모든 줄 바꿈을 RFC 2049의 정규형인 CRLF로 변환해야 한다. 다만 이는 Content-Encoding의 존재나 일부 문자셋이 CR과 LF를 각각 옥텟 13과 10으로 사용하지 않는다는 사실로 인해 복잡해질 수 있다.

변환은 원본 콘텐츠에 적용된 어떤 암호화 체크섬도 손상시킬 수 있으므로, 원본 콘텐츠가 이미 정규형이라면 정규형 사용이 권장된다.

HTTP/1.1은 날짜 비교를 단순화하기 위해 제한된 날짜 형식 집합(Section 5.6.7 of [HTTP])을 사용한다. 다른 프로토콜로부터의 프록시나 게이트웨이는 메시지에 존재하는 Date 헤더 필드가 HTTP/1.1 형식 중 하나에 일치하도록 보장하고 필요시 날짜를 재작성해야 한다.

MIME에는 HTTP의 Content-Encoding 헤더 필드와 동등한 개념이 없다. 이는 미디어 타입에 대한 수식어로 작용하므로, HTTP에서 MIME 준수 프로토콜로의 프록시 및 게이트웨이는 Content-Type 헤더 필드의 값을 변경하거나 전송 전에 표현을 디코드해야 한다. (일부 실험적 응용에서는 ";conversions=<content-coding>" 같은 미디어 타입 매개변수를 사용했으나 이는 MIME 표준의 일부가 아니다.)

HTTP는 MIME의 Content-Transfer-Encoding 필드를 사용하지 않는다. MIME 준수 프로토콜에서 HTTP로의 프록시 및 게이트웨이는 응답 메시지를 HTTP 클라이언트에게 전달하기 전에 모든 Content-Transfer-Encoding을 제거해야 한다.

HTTP에서 MIME 준수 프로토콜로의 프록시 및 게이트웨이는 목적지 프로토콜의 제한에 따른 "안전한 전송"을 보장하기 위해 메시지가 올바른 형식과 인코딩으로 변환되도록 책임을 져야 한다. 이러한 변환이 목적지 프로토콜에서의 안전 전송 가능성을 높인다면 적절한 Content-Transfer-Encoding을 적용하고 라벨링해야 한다.

MHTML([RFC2557]) 구현과 코드를 공유하는 HTTP 구현체는 MIME의 행 길이 제한을 인지해야 한다. HTTP는 이러한 제한이 없으므로 긴 행을 접지 않는다. HTTP로 전송되는 MHTML 메시지는 MHTML의 모든 관습(행 길이 제한 및 접기, 정규화 등)을 준수해야 한다. HTTP는 메시지 본문을 수정 없이 전송하며, "multipart/byteranges" 타입을 제외하고는 콘텐츠나 그 안에 포함된 MIME 헤더 행을 해석하지 않는다.

HTTP/0.9는 요청에 헤더 필드를 지원하지 않았기 때문에 이름 기반 가상 호스트(요청의 Host 헤더 필드 검사로 리소스 선택)를 지원할 메커니즘이 없다. 이름 기반 가상 호스트를 구현하는 서버는 HTTP/0.9 지원을 비활성화해야 한다. HTTP/0.9로 보이는 대부분의 요청은 실제로는 클라이언트가 request-target을 올바르게 인코딩하지 못해 잘못 구성된 HTTP/1.x 요청이다.

HTTP의 설계 목표, 역사, 아키텍처, 적합성 기준, 프로토콜 버전 관리, URI, 메시지 라우팅 및 헤더 필드에 관한 대부분의 섹션이 [HTTP]로 이동되었다. 이 문서는 HTTP/1.1에 특정한 메시지 구문과 연결 관리 요구사항으로 축소되었다.

콘텐츠 외부에서의 단독 CR은 금지되었다. (Section 2.2)

authority-form의 ABNF 정의는 포트가 선택적인 URI의 보다 일반적인 authority 구성 요소에서 CONNECT에 요구되는 host:port 형식으로 변경되었다. (Section 3.2.3)

수신자는 모호한 메시지 프레이밍을 처리할 때 스머글링/분할 공격을 피해야 한다는 요구사항이 추가되었다. (Section 6.1)

청크 확장(ABNF)에서 ";" 및 "=" 주위의 (나쁜) 공백이 다시 도입되었다. 공백은 RFC7230에서 제거되었으나 그 변경이 기존 구현을 깨뜨리는 것으로 밝혀졌다. (Section 7.1.1)

트레일러 필드의 의미는 이제 청크 전송 코딩의 세부 사항을 초월한다. 청크 디코드 알고리즘(Section 7.1.3)은 트레일러 필드를 헤더 섹션과 분리하여 저장/전달하도록 권장하고, 수신자가 해당 필드 정의가 병합을 허용하고 병합 방법을 정의하는 경우에만 헤더 섹션으로 병합을 허용하며, 그렇지 않으면 트레일러 필드를 병합하지 말고 폐기하도록 업데이트되었다. 트레일러 부분은 이제 헤더 섹션과 더 일관되고 본문 부분과 더 구분되도록 트레일러 섹션이라고 불린다. (Section 7.1.2)

TE 헤더 필드에서 순위로 사용되는 "q"의 사용과 충돌을 피하기 위해 "q"라는 전송 코딩 매개변수는 허용되지 않는다. (Section 7.3)