RFC 번역본

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

메시지 내에서 “http” URI 참조가 요청 대상 또는 헤더 필드 값으로 생성되는 경우 보낸 사람은 userinfo 하위 구성 요소(및 해당"@"구분 기호)를 생성해서는 안 된다.(MUST NOT) 신뢰할 수 없는 소스에서 수신한 “http"URI 참조를 사용하기 전에 수신자는 userinfo에 대해 구문 분석하고 이 참조의 존재를 오류로 간주해야 한다.(SHOULD); 피싱 공격을 위해 권한을 숨기는 데 사용될 가능성이 높다.

사용자 에이전트는 첫 번째 HTTP 요청을 보내기 전에 강력한 암호화 사용, end-to-end, 통해 원서버에 대한 커넥션이 안전한지 확인해야 한다.(MUST)

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

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

HTTP는 Section 2.5에서 설명한 것처럼 request-line의 길이에 대해 미리 정의된 제한을 두지 않는다. 구현한 것보다 더 긴 메서드를 수신한 서버는 501(Not Implemented)상태 코드로 응답해야 한다.(SHOULD) request-target을 구문 분석하려는 URI보다 긴 414(URI Too Long)상태 코드로 응답해야 한다.(MUST) ([RFC95231]의 Section 6.5.12 참조)

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

서버는 헤더 필드에는 조건, 인증 자격 증명 또는 요청 처리에 영향을 미칠 수 있는 의도적으로 잘못된 중복 헤더 필드가 포함될 수 있으므로 전체 요청 헤더 부문을 받을 때 까지 대상 리소스에 요청을 적용하면 안 된다.(MUST NOT) 발신자는 헤더 필드의 전체 필드 값이 쉼표로 구분된 목록 [i.e., #(values)]으로 정의되어 있거나 헤더 필드가 잘 알려 진 예외(아래 설명 참조)가 아닌 한, 메시지에 동일한 필드 이름을 가진 헤더 필드를 여러개 생성해서는 안 된다.(MUST NOT)

BWS 규칙은 오직 역사적인 이유로 선택적인 공백(OWS)을 허락하는 문법에서 사용된다. 발신자는 메시지에서 BWS를 생성해서는 안된다.(MUST NOT) 수신자는 이러한 잘못된 공백을 구문 분석한 후 프로토콜 요소를 해석하기 전에 제거해야 한다.(MUST)

헤더 field-name과 콜론 사이에는 공백이 허용되지 않는다. 과거에는 이러한 공백 처리에 차이가 있어 요청 라우팅 및 응답 처리 시 보안 취약성이 발생했다. 서버는 응답 코드가 400(Bad Request)과 함께 헤더 필드 이름과 콜론 사이에 공백이 포함된 수신된 요청 메시지를 거부해야 한다.(MUST) 프락시는 메시지를 다운 스트림으로 전달하기 전에 응답 메시지에서 이러한 공백을 모두 제거해야 한다.(MUST)

역사적으로, HTTP 헤더 필드 값을 각 여러 줄 앞에 최소 하나 이상의 공백 또는 수평 탭(obs-fold)을 두어 여러줄로 확장할 수 있었다. 이 명세는 message/http 미디어 타입(Section 8.3.1)을 제외하고 이러한 라인 폴딩을 제거한다. 발신자는 메시지가 message/http 미디어 타입 내에서 패키징 되도록 의도되지 않은 한 라인 폴딩(즉, obs-fold 규칙과 일치하는 field-value 포함)을 포함하는 메시지를 생성해서는 안 된다.(MUST NOT)

message/http 컨테이너 내에 없는 요청 메시지에서 obs-fold를 수신하는 서버는 400(Bad Request)을 발송하여 메시지를 거부해야 하며,(MUST) 가급적이면 사용되지 않는 라인 폴딩이 허용되지 않는다는 것을 설명하는 표현으로, 필드 값을 해석하거나 또는 메세지를 다운스트림으로 전달하기 전에, 수신된 각 obs-fold를 하나 이상의 SP octet으로 대체해야 한다.

message/http 컨테이너 내에 없는 응답 메시지에서 obs-fold를 수신하는 프락시 또는 게이트 웨이는 메시지를 삭제하고 502(Bad Gateway) 응답으로 대체해야 하고,(MUST) 가급적이면 사용되지 않는 라인 폴딩이 허용되지 않는 다는 것을 설명하는 표현으로, 필드 값을 해석하거나 또는 메시지를 다운 스트림으로 전달하기 전에, 수신된 각 obs-fold를 하나 또는 더 많은 SP octets 으로 대체해야 한다.

처리하려는 것보다 큰 요청 헤더 필드 또는 필드 집합을 수신하는 서버는 적절한 4xx(Client Error)상태 코드로 응답해야 한다.(MUST) 이러한 헤더 필드를 무시하면 서버의 smuggling 공격 취약성이 증가한다(Section 9.5).

페이 로드 본문 크기를 미리 알지 못할 때 메시지 프레임에 중요한 역할을 하기 때문에 수신자는  청크 전송 코딩(Section 4.1)을 구문 분석할 수 있어야 한다. (MUST) 발신자는 메시지 본문에 두번 이상 청크 분할된 메시지를 적용해서는 안 된다.(MUST NOT) (i.e., 이미 청크 분할된 메시지는 허용되지 않는다). 청크 분할 이외의 전송 코딩이 요청 페이 로드 본문에 적용되는 경우, 발신자는 메시지가 올바르게 프레임 되었는지 확인하기 위해 최종 전송 코딩으로 청크 분할을 적용해야 한다.(MUST) 청크 분할 이외의 전송 코딩이 응답 페이 로드 본문에 적용되는 경우 발신자는 최종 전송 코딩으로 청크 분할을 적용하거나 커넥션을 닫아 메시지를 종료해야 한다.

서버는 상태 코드가 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.0 지원을 알리는 용도로 구현하는 것은 transfer-encoded 페이로드를 처리하기 위한 방법을 이해하지 못할 것으로 가정한다. 클라이언트는 서버가 HTTP/1.1(이상)요청을 처리 할 수 있을 것이라고 알지 못하는 한 Transfer-Encoding을 포함하는 요청을 보내면 안 된다.(MUST NOT) 이러한 인지는 특정 사용자 구성 형태이거나 이전에 수신한 응답 버전을 기억함으로써 가능하다. 해당 요청이 HTTP/1.1(또는 그 이상)을 나타내지 않는 한 서버는 Transfer-Encoding을 포함하는 응답을 보내면 안 된다.(MUST NOT)

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

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