3. Message Format

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

HTTP 메시지를 분석하는 일반적인 절차는 start-line을 읽고, 각 헤더 필드를 빈 행까지 필드 이름으로 해시 테이블로 읽은 다음 분석된 데이터를 사용하여 메시지 본문이 필요한지 여부를 확인하는 것이다. 메시지 본문이 표시된 경우, 메시지 본문 길이와 동일한 octet의 양을 읽거나 커넥션을 닫을 때까지 스트림으로 읽는다.

• 수신자는 반드시 HTTP 메시지를 US-ASCII [USASCII]의 상위 집합인 인코딩에서 octet로 구 문 분석해야 한다.(MUST)

• 발신자는 start-line과 첫 번째 헤더 필드 사이에 공백을 보내면 안 된다.(MUST NOT)

• start-line 과 첫 번째 헤더 필드 사이의 공백을 수신하는 수신자는 메시지를 유효하지 않은 것으로 거부 하거나 메시지를 더 이상 처리하지 않고 각 공백이 지정된 줄을 소비해야 한다.(MUST) (i.e., 공 백이오는모든후속줄과함께, 올바르게형성된헤더필드가수신되거나헤더부문이끝날 때까지, 전체 라인을 무시한다)

3.1 Start Line

요청과 응답 메세지의 유일한 차이는 start line 과 메세지 body의 길이를 결정하기 위한 알고리즘이다. 실질적으로는 start line으로 구분을 할 수 있지만, 서버는 요청만 받도록 구현되고 클라이언트는 응답만 받도록 구현된다.

start-line = request-line / status-line

3.1.1 Request Line

요청 메시지의 첫 번째 줄은 request-line 이다.

request-line = method SP request-target SP HTTP-version CRLF

method 토큰은 대상 리소스를 실행하기 위한 요청 메서드를 표시한다. 요청 메서드는 대소문자를 구분한다.

request-target은 Section 5.3에 정의된 대로 요청을 적용할 대상 리소스를 식별한다.

• 유효하지 않은 request-line의 수신자는 400(Bad Request) 오류 또는 301(Moved Permanently) 리다이렉트로 응답해야 하며, request-target은 적절히 인코딩되어야 한다.(SHOULD)

• 유효하지 않은 request-line은 요청 체인을 따라 보안 필터를 우회하도록 의도적으 로 조작될 수 있으므로 수신자는 리다이렉트 없이 요청을 자동 수정하고 처리해서는 안된다.(SHOULD NOT)

HTTP는 Section 2.5에서 설명한 것처럼 request-line의 길이에 대해 미리 정의된 제한을 두 지 않는다.

• 구현한 것보다 더 긴 메서드를 수신한 서버는 501(Not Implemented)상태 코드 로 응답해야 한다.(SHOULD)

• request-target을 구문 분석하려는 URI보다 긴 414(URI Too Long)상태 코드로 응답해야 한다.(MUST)([RFC95231]의 Section 6.5.12 참조)

• 모든 HTTP 발신자와 수신자는, 최소 8000 octet 길이의 request-line을, 지원하는 것을 권장한 다.(RECOMMENDED)

3.1.2 Status Line

응답 메시지의 첫 번째 줄은 status-line 이다.

status-line = HTTP-version SP status-code SP reason-phrase CRLF

reason-phrase 요소는 숫자 상태 코드와 관련된 텍스트 설명을 제공하는 유일한 목적으로 존재한다.

• 클라이언트는 reason-phase 내용을 무시해야 한다.(SHOULD)

reason-phrase = *( HTAB / SP / VCHAR / obs-text )

3.2 Header Fields

각 헤더 필드는 대소문자를 구분하지 않는 필드 이름 뒤에 콜론(":"), 선택적 앞의 공백 (OWS), 필드 값, 선택적 뒤의 공백(OWS)으로 구성된다.

header-field = field-name ":" OWS field-value OWS

3.2.1 Field Extensibility

지정된 메시지에 사용되는 헤더 필드의 개수에도 제한이 없다.

• field-name이 Connection 헤더 필드(Section 6.1)에 나열되어 있지 않거나 프시가 이러 한 필드를 차단하거나 변환하도록 특별히 구성되어 있지 않는 경우, 프록는 인식하지 못하는 헤더 필드를 전달해야 한다.(MUST)

• 다른 수신자는 인식할 수 없는 헤더 필드를 무시해야 한 다.(SHOULD)

정의된 모든 헤더 필드는 [RFC7131] Section 8.3에 설명된 대로 "Message Headers" 레지스트리의 IANA에 등록되어야 한다.

3.2.2 Field Order

헤더 필드의 순서는 중요하지 않으나 요청 시 Host, 응답 시 Date 등 제어 데이터가 포함된 헤더 필드를 먼저 보내 구현 시 메시지를 처리하지 않을 시기를 결정하는 것이 좋다.

• 서버는 헤더 필드에는 조건, 인증 자격 증명 또는 요청 처리에 영향을 미칠 수 있는 의도적으로 잘못된 중복 헤더 필드가 포함될 수 있으므로 전체 요청 헤더 부문을 받을 때까지 대상 리소스에 요청을 적용하면 안 된다.(MUST NOT)

• 발신자는 헤더 필드의 전체 필드 값이 쉼표로 구분된 목록 [i.e., #(values)]으로 정의되어 있거나 헤더 필드가 잘 알려진 예외(아래 설명 참조)가 아닌 한, 메시지에 동일한 필드 이름을 가진 헤더 필드를 여러개 생성해서는 안 된다.(MUST NOT)

• 수신자는 각 후속 필드 값을 쉼표로 구분하여 결합된 필드 값에 순서대로 추가하여 메시지의 의미론을 변경하지 않고 동일한 필드 이름을 가진 여러 헤더 필드를 하나의 “field-name: field-value“ 쌍으로 결합할 수 있다.(MAY)

• 메시지를 전달할 때 프락시는 이러한 필드 값의 순서를 변경해서는 안 된다.(MUST NOT)

참고: 실제로 "Set-Cookie" 헤더 필드([RFC6065])는 응답 메시지에 여러번 나타나며 목록 구문을 사용하지 않아 동일한 이름의 여러 헤더 필드에서 위의 요구 사항을 위반한다. 필드 값을 하나의 필드 값으로 결합할 수 없으므로, 수신자는 헤더 필드를 처리하는 동안 "Set-Cookie"를 특별한 경우로 처리해야 한다. (자세한 내용은 [Kri2001]의 Appendix A.2.3 을 봐라.)

3.2.3 Whitespace

이 명세는 OWS(optional whitespace 선택적 공백), RWD(required whitespace 필수 공백)및 BWS(bad whitespace "불량" 공백)의 사용을 나타내는 세 가지 규칙을 사용한다.

• 가독성을 향상시키기 위해 선택적인 공백(OWS)을 선호하는 프로토콜 요소의 경우, 발신자는 단일 SP로서 선택적인 공백(OWS)를 생성해야 한다. (SHOULD)

• 그렇지 않은경우, 발신자는 내부 메시지 필터링 중에 유효하지 않거나 원하지 않는 프로토콜 요소를 화이트 아웃하는데 필요한 경우를 제외하고 선택적 공백을 생성해서는 안 된다.(SHOULD NOT)

RWS 규칙은 필드 토큰을 분리하기 위해 하나 이상의 선형 공백 octets이 필요한 경우에 사용된다.

• 발신자는 단일 SP로서 RWS를 생성해야 한다.(SHOULD)

BWS 규칙은 오직 역사적인 이유로 선택적인 공백(OWS)을 허락하는 문법에서 사용된다.

• 발신자는 메시지에서 BWS를 생성해서는 안된다.(MUST NOT)

• 수신자는 이러한 잘못된 공백을 구문 분석한 후 프로토콜 요소를 해석하기 전에 제거해야 한다.(MUST)

3.2.4 Field Parsing

메시지는 개별 헤더 필드 이름과 독립적으로 일반적인 알고리즘을 사용하여 구문 분석된다.

헤더 field-name과 콜론 사이에는 공백이 허용되지 않는다.

• 서버는 응답 코드가 400(Bad Request)과 함께 헤더 필드 이름과 콜론 사이에 공백이 포함된 수신된 요청 메시지 를 거부해야 한다.(MUST)

• 프락시는 메시지를 다운 스트림으로 전달하기 전에 응답 메시지에서 이러한 공백을 모두 제거해야 한다.(MUST)

역사적으로, HTTP 헤더 필드 값을 각 여러 줄 앞에 최소 하나 이상의 공백 또는 수평 탭(obs- fold)을 두어 여러줄로 확장할 수 있었다.

• 발신자는 메시지가 라인 폴딩(즉, obs-fold 규칙과 일치하는 field- value 포함)을 포함하는 메시지를 생성해서는 안된다. 단, message/http 미디어 타입 내에서 패키징 되도록 의도된것들은 허용한다. (MUST NOT)

• message/http 컨테이너 내에 없는 요청 메시지에서 obs-fold를 수신하는 서버는 400(Bad Request)을 발송하여 메시지를 거부해야 한다.(MUST)

• message/http 컨테이너 내에 없는 응답 메시지에서 obs-fold를 수신하는 프락시 또는 게이트웨이는 메시지를 삭제하고 502(Bad Gateway) 응답으로 대체해야 한다. (MUST)

• message/http 컨테이너 내에 없는 응답 메시지에서 obs-fold를 수신하는 사용자 에이전트는 필드 값을 해석하기 전에, 수신된 각 obs-fold를 하나 또는 더 많은 SP octets 으로 대체해 야 한다.(MUST)

Is it possible to include multiple CRLFs in a HTTP header-field?Stack Overflow

• 새로 정의된 헤더 필드는 필드 값을 US-ASCII octet으로 제한해야 한다.(SHOULD)

• 수신자는 필드 내용(obs-text)의 다른 octet을 불투명 데이터로 처리해야 한다.(SHOULD)

3.2.5 Field Limits

• 처리하려는 것보다 큰 요청 헤더 필드 또는 필드 집합을 수신하는 서버는 적절한 4xx(Client Error)상태 코드로 응답해야 한다.(MUST)

이러한 헤더 필드를 무시하면 서버의 smuggling 공격 취약성이 증가한다(Section 9.5).

3.2.6 Field Value Components

대부분의 HTTP 헤더 필드 값은 공백 또는 특정 구분 문자로 구분된 일반 구문 구성 요소 (token, quoted-string 및 comment)를 사용하여 정의된다. 구분 기호는 토큰 (DQUOTE and “(),/:;<=>?@[\]{}")에 허용되지 않는 US-ASCII 시각적 문자 집합에서 선택된다.

텍스트 문자는 double-quote로 묶여 있으면 하나의 값으로 분석된다.

• quoted-string 값을 처리하는 수신자는 quoted-pair를 백슬래시로 octet에 의해 대체된 것 처럼 처리해야 한다.(MUST)

• 발신자는 DQUOTE와 백슬래시 octets을 해당 문자에 인용해야 하는 경우를 제외하고 quoted-string에서 quoted-pair를 생성면 안 된다.(SHOULD NOT)

• 발신자는 괄호[“(“and”)”]와 backslash octets를 해당 주석에 인용해야 하는 경우를 제외하고 comment 내에 quoted-pair를 생성하면 안 된다.(SHOULD NOT)

3.3 Message Body

HTTP 메시지의 메시지 본문(있는 경우)은 해당 요청 또는 응답의 페이로드 본문을 전달하는데 사용된다.

메시지에서 메시지 본문이 허용되는 시기에 대한 규칙은 요청과 응답에 따라 다르다.

요청에서 메시지 본문이 있으면 Content-Length 또는 Transfer-Encoding 헤더 필드로 표시된다. 응답에서 메시지 본문의 존재 여부는 응답하는 요청 메서드와 응답 상태 코드(Section 3.1.2)에 따라 달라진다.

• HEAD 요청 메서드([RFC7231]의 Section 4.3.2)에 대한 응답은 관련 응답 헤더 필드(예:Transfer-Encoding, Content-Length, 등)가 있는 경우 요청 메서드가 GET([RFC7231]의 Section 4.3.1) 되었을 때의 값만 나타내므로 메시지 본문을 포함하지 않는다.

• CONNECT 요청 메서드([RFC7231]의 Section 4.3.6)에 2xx (Successful) 응답은 메시지 본문 대신 터널 모드로 전환한다.

• 모든 1xx (informational), 204 (No Content) 및 304 (Not Modified) 응답에는 메시지 본문이 포함되지 않는다.

• 다른 모든 응답에는 메시지 본문이 포함되지만, 본문의 길이는 0일 수 있다.

3.3.1 Transfer-Encoding

Transfer-Encoding 헤더 필드에는 메시지 본문을 형성하기 위해 페이 로드 본문에 적용된(또 는 적용될) 전송 코딩 순서에 해당하는 전송 코딩 이름을 나열한다.

Transfer-Encoding = 1#transfer-coding

HTTP의 경우, Transfer-Encoding은 주로 동적으로 생성되는 페이 로드를 정확하게 지정하고 전송 효율성 또는 보안을 위해서만 적용되는 페이 로드 인코딩과, 선택된 리소스의 특징인 페이 로드 로 구분하기 위한 것이다.

• 페이 로드 본문 크기를 미리 알지 못할 때 메시지 프레임에 중요한 역할을 하기 때문에 수신자는 청 전송 코딩(Section 4.1)을 구문 분석할 수 있어야 한다. (MUST)

• 발신자는 메시지 본문 에 두번 이상 청크 분할된 메시지를 적용해서는 안 된다.(MUST NOT) (i.e., 이미 청크 분할된 메 시지는 허용되지 않는다).

• 청크 분할 이외의 전송 코딩이 요청 페이 로드 본문에 적용되는 경 우, 발신자는 메시지가 올바르게 프레임 되었는지 확인하기 위해 최종 전송 코딩으로 청크 분 할을 적용해야 한다.(MUST)

다음

Transfer-Encoding: gzip, chunked

메시지 본문을 구성하는 동안 페이 로드 본문이 gzip 코딩을 사용하여 압축된 다음 chunked 코드를 사용하여 분할된 것을 나타낸다.

• HEAD 요청에 응답 하거나 또는 304(Not Modified) 응답 ([RFC7232]의 Section 4.1)을 통해 GET 요청에 응답 하거나, 메시지 본문을 포함하거나 조건 없는 GET 요청인 경우 원서버가 메시지 본문에 전송 코딩을 적용 했을거라고 표시하기 위해 Transfer-Encoding이 보내질 수 있다.(MAY)

• 서버는 상태 코드가 1xx (Informational) 또는 204 (No Content) 응답에서 Transfer- Encoding 헤더 필드를 보내면 안 된다.(MUST NOT)

• 서버는 CONNECT 요청에 2xx (Successful) 응답에서 Transfer-Encoding 헤더 필드를 보내 면 안 된다.(MUST NOT) ([RFC7131]의 Section 4.3.6).

HTTP/1.1에 Transfer-Encoding이 추가되었다.

• 클라이언트는 서버가 HTTP/1.1(이상)요청을 처리 할 수 있을 것이라고 알지 못하는 한 Transfer-Encoding을 포함하는 요청을 보내면 안 된다.(MUST NOT)

• 해당 요청이 HTTP/1.1(또는 그 이상)을 나타내지 않는 한 서버는 Transfer-Encoding을 포함하는 응답을 보내면 안 된다.(MUST NOT)

• 이해하지 못하는 전송 코딩과 함께 요청 메시지를 받는 서버는 501 (Not Implemented)로 응답해야 한다.(SHOULD)

3.3.2 Content-Length

메시지에 Transfer-Encoding 헤더 필드가 없는 경우, Content-Length 헤더 필드는 잠재적 페이 로드 본문에 대해 예상되는 크기를 10진수로 제공할 수 있다.

Content-Length = 1*DIGIT

• 발신자는 Transfer-Encoding 헤더 필드를 포함하는 메시지에서 Content-Length 헤더 필드를 보내면 안 된다.(MUST NOT)

• Transfer-Encoding 없이 전송하고 요청 메서드가 동봉된 페이 로드 본문에 대한 의미를 정의 할 때 사용자 에이전트는 요청 메시지에 Content-Length를 보내야 한다.(SHOULD)

• 요청 메시지에 페이 로드 본문이 포함되어 있지 않고 메서드 의미론이 이러한 본문을 예상하지 않는 경우 사용자 에이전트는 Content-length 헤더 필드를 발송해는 안 된다.(SHOULD NOT)

• 서버는 HEAD 요청에 대한 응답으로 Content-Length 헤더 필드를 전송할 수 있다. (MAY)

• 서버는 동일한 요청에서 GET 메소드를 사용한 경우 응답의 페이로드 본문에 전송 된 10진수와 Content-Length의 field-value가 같지 않는 한, 서버는 응답으로 Content-Length를 보내서는 안 된다.(MUST NOT)

서버는 조건부 GET 요청에 대해 304 (Not Modified) 응답의 Content-Length 헤더 필드를 보낼 수 있다.

• 필드 값이 동일한 요청에 대한 200 (OK) 응답의 페이로드 본문에서 전송된 10진수와 Content-Length의 field-value가 같지 않는 한, 서버는 응답으로 Content-Length를 보내서는 안 된다.(MUST NOT)

• 서버는 상태 코드가 1xx (Informational) 또는 204 (No Content)인 응답에서 Content- Length헤더 필드를 보내면 안 된다.(MUST NOT)

• 서버는 CONNECT 요청에 대한 2xx (Successful) 응답에서 Content-Length 헤더 필드를 보 내서는 안 된다.(MUST NOT) ([RFC7231]의 Section 4.3.6)

• 위에 정의된 경우와 별도로, Transfer-Encoding이 없는 경우, 전체 헤더 부문을 보내기 전에 페이 로드 본문 크기를 알고 있는 원서버는 Content-Length 헤더 필드를 보내야 한다. (SHOULD)

Content-Length 필드 값이 0보다 크거나 같으면 유효하다.

• 페이 로드 길이에 대한 사전 정의 된 제한이 없으므로 수신자는 잠재적으로 큰 10진수 숫자를 예측하고 정수 변환 오버 플로우 로 인한 구문 분석 오류를 방지해야 한다.(MUST)

• 여러 Content-Length 헤더 필드와 함께 동일한 10진수로 구성하는 field-value를 가지고 있거나, 또는 단독 Content-Length 헤더 필드와 함께 동일한 10진수의 리스트로 구성하는 field-value를 가지고 있거나(예: “Content-length:42, 42”), 중복된 Content-Length 헤더 필드가 생성되거나 업스트림 메시지 처리기에 의해 결합된 것으로 나타나는 메시지를 받은 경우, 그때 수신자는 유효하지 않은 메시지를 거부하거나, 메시지 본문 길이를 결정하는것 또는 전송되기 전에 10진수를 포함하는 유효한 단독 Content-Length와 함께 중복된 field-value 를 대체해야 한다.(MUST)

3.3.3 Message Body Length

메시지 본문의 길이는 다음 중 하나에 의해 결정된다(우선 순위 순서대로):

본문 참조.

3.4 Handling Imcomplete Messages

일반적으로 취소된 요청 또는 트리거 된 시간 초과 예외 때문에 발생하는 불완전한 요청 메시지를 수신하는 서버는 커넥션을 닫기 전에 오류 응답을 보낼 수 있다.(MAY)

커넥션이 조기에 닫히거나 청크 분할된 전송 코딩을 디코딩 하는 데 실패할 때 발생할 수 있는 불완전한 응답 메시지를 수신하는 클라이언트는 메시지를 반드시 불완전한 메시지로 기록해야 한다.(MUST)

RFC 7230 번역 pdf

인코딩을 종료하는 zero-sized(0)의 청크가 수신되지 않으면 청크 전송 코딩을 사용하는 메시지 본문은 불완전하다.

수신된 메시지 본문의 크기(in octets)가 Content-Length에서 지정한 값보다 작은 경우 유효한 Content-Length를 사용하는 메시지는 불완전하다.

3.5 Message Parsing Robustness

• HTTP/1.1 사용자 에이전트는 추가 CRLF로 시작하거나 요청을 반드시 따르면 안 된다.(MUST NOT)

• line-ending으로 요청 메시지 본문을 종료해야 하는 경우, 사용자 에이전트는 메시지 본문 길이의 부분으로서 종료 CRLF octet을 세어야 한다.(MUST)

• HTTP 요청 메시지만 청취하거나, HTTP 요청 메시지이기 위해 start-line에서 나타나는 내용을 처리하는 서버가 위에 나열된 엄격함 예외 외에도 HTTP-message 문법과 일치하지 않는 octets의 시퀸스를 수신하는 경우, 서버는 400 (Bad Request)응답으로 응답해야 한다. (SHOULD)