HTTP 의미론

"http" URI 스킴은 주어진 포트의 TCP([TCP]) 연결을 수신하는 잠재적 HTTP 출처(origin) 서버에 의해 관리되는 계층적 네임스페이스 내에서 식별자를 생성하기 위해 정의됩니다.

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

"http" URI의 출처 서버는 호스트 식별자([URI], 섹션 3.2.2) 및 선택적 포트 번호([URI], 섹션 3.2.3)를 포함하는 authority 구성요소로 식별됩니다. 포트 하위 구성요소가 비어 있거나 주어지지 않으면 TCP 포트 80(WWW 서비스의 예약 포트)이 기본값입니다. 출처는 식별된 리소스를 대상으로 하는 요청에 대해 권한을 갖고 응답할 권한이 누구에게 있는지를 결정합니다(섹션 4.3.2 참조).

발신자는 호스트 식별자가 비어 있는 "http" URI를 생성해서는 반드시 해서는 안 됨. 그러한 URI 참조를 처리하는 수신자는 이를 잘못된 것으로 거부해야 한다.

계층적 경로 구성요소 및 선택적 쿼리 구성요소는 해당 출처 서버의 네임스페이스 내에서 대상 리소스를 식별합니다.

"https" URI 스킴은 주어진 포트에서 TCP 연결을 수신하고 HTTP 통신을 위해 보안된 TLS([TLS13]) 연결을 설정할 수 있는 잠재적 출처 서버에 의해 관리되는 계층적 네임스페이스 내에서 식별자를 생성하기 위해 정의됩니다. 여기서 보안됨은 특히 서버가 식별된 권한(authority)을 대신하여 행동하는 것으로 인증되었고, 해당 서버와의 모든 HTTP 통신이 클라이언트와 서버 모두에게 허용 가능한 기밀성 및 무결성 보호를 가진다는 것을 의미합니다.

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

"https" URI의 출처 서버는 authority 구성요소로 식별되며, 이는 호스트 식별자([URI], 섹션 3.2.2)와 선택적 포트 번호([URI], 섹션 3.2.3)를 포함합니다. 포트 하위 구성요소가 비어 있거나 주어지지 않으면 TCP 포트 443(HTTP over TLS의 예약 포트)이 기본값입니다. 출처는 식별된 리소스를 대상으로 하는 요청에 권한 있게 응답할 권한이 누구에게 있는지를 결정합니다(섹션 4.3.3 참조).

발신자는 호스트 식별자가 비어 있는 "https" URI를 생성해서는 반드시 해서는 안 됨. 그러한 URI 참조를 처리하는 수신자는 이를 잘못된 것으로 거부해야 한다.

계층적 경로 구성요소 및 선택적 쿼리 구성요소는 해당 출처 서버의 네임스페이스 내에서 대상 리소스를 식별합니다.

클라이언트는 "https" 리소스에 대한 HTTP 요청이 통신되기 전에 보안이 확보되었는지 반드시 확인하고, 해당 요청에 대한 응답도 보안된 응답만 수락해야 합니다. 어떤 암호화 메커니즘이 클라이언트와 서버에 허용되는지는 일반적으로 협상되어 시간이 지남에 따라 변경될 수 있습니다.

"https" 스킴을 통해 제공되는 리소스는 "http" 스킴과 정체성이 공유되지 않습니다. 이들은 별도의 네임스페이스를 갖는 서로 다른 출처입니다. 그러나 쿠키 프로토콜([COOKIE])과 같이 동일한 호스트에 대한 모든 출처에 적용되도록 정의된 HTTP의 확장들은 한 서비스에서 설정한 정보가 호스트 도메인 그룹 내의 다른 서비스와의 통신에 영향을 줄 수 있게 합니다. 이러한 확장들은 보안 연결에서 얻은 정보가 의도치 않게 보안되지 않은 컨텍스트에서 교환되지 않도록 매우 주의해서 설계되어야 합니다.

"http" 또는 "https" 스킴을 가진 URI는 섹션 6에 정의된 방법에 따라 정규화되고 비교됩니다. 여기서는 각 스킴에 대해 위에서 설명한 기본값을 사용합니다.

HTTP는 동등성 결정에 특정 방법의 사용을 요구하지 않습니다. 예를 들어, 캐시 키는 문법 기반 정규화 후 간단한 문자열로 비교되거나, 스킴 기반 정규화 후 비교될 수 있습니다.

• 포트가 스킴의 기본 포트와 같으면 포트 하위 구성요소를 생략하는 것이 정규형입니다.
• OPTIONS 요청의 대상이 아닌 경우, 빈 경로 구성요소는 "/"의 절대 경로와 동등하므로 정규형은 "/" 경로를 제공하는 것입니다.
• 스킴과 호스트는 대소문자를 구분하지 않으며 일반적으로 소문자로 제공됩니다; 다른 모든 구성요소는 대소문자를 구분하여 비교됩니다.
• "예약된" 집합에 속하지 않는 문자들은 해당 백분율 인코딩된 옥텟과 동등합니다: 정규형은 이를 인코딩하지 않는 것입니다(자세한 내용은 2.1 및 2.2 참조).

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

정규화 후(어떤 방법을 사용하든) 동등한 두 HTTP URI는 같은 리소스를 식별한다고 가정할 수 있으며, 어떤 HTTP 구성요소든 정규화할 수 있습니다. 결과적으로, 정규화 후 동등한 HTTP URI로 서로 다른 리소스를 식별해서는 안 됩니다 (rfc3986 섹션 6.2 참조).

권한(authority)에 대한 URI 일반 문법은 사용자 인증 정보를 URI에 포함하기 위한 userinfo 하위 구성요소([URI], 섹션 3.2.1)도 포함합니다. 해당 하위 구성요소에서 "user:password" 형식의 사용은 더 이상 권장되지 않습니다.

일부 구현은 명령 호출 옵션, 구성 파일 또는 북마크 목록 등 내부 구성의 인증 정보 저장을 위해 userinfo 구성요소를 사용하지만, 그러한 사용은 사용자 식별자나 비밀번호를 노출할 수 있습니다.

발신자는 메시지 내에서 대상 URI나 필드 값으로 "http" 또는 "https" URI 참조를 생성할 때 userinfo 하위 구성요소(및 해당 "@" 구분자)를 생성해서는 반드시 해서는 안 됩니다.

신뢰할 수 없는 출처에서 수신한 "http" 또는 "https" URI 참조를 사용하기 전에, 수신자는 userinfo를 파싱하고 그 존재를 오류로 처리하는 것이 권고됨; 이는 피싱 공격을 위해 권한을 숨기려고 사용되고 있을 가능성이 높습니다.

프래그먼트 식별자는 섹션 3.5에 정의된 바와 같이, 스킴과 무관하게 부차적 리소스를 간접적으로 식별할 수 있게 합니다. 일부 프로토콜 요소는 프래그먼트를 포함할 수 있는 URI를 허용하는 반면, 다른 요소는 허용하지 않습니다. 허용되는 경우에는 해당 ABNF 규칙을 사용하여 구분하고, 그렇지 않은 경우에는 프래그먼트를 제외하는 특정 규칙을 사용합니다.

주어진 URI의 출처는 스킴, 호스트 및 포트의 삼중으로, 스킴과 호스트는 소문자로 정규화하고 포트는 선행 0을 제거하여 정규화한 것입니다. URI에서 포트가 생략되면 해당 스킴의 기본 포트가 사용됩니다. 예를 들어, 다음 URI는

   https://Example.Com/happy.js

다음과 같은 출처를 가집니다

   { "https", "example.com", "443" }

   https://example.com:443

각 출처는 자체 네임스페이스를 정의하고 해당 네임스페이스 내의 식별자가 리소스에 어떻게 매핑되는지를 제어합니다. 결과적으로 출처가 유효한 요청에 일관되게 응답하는 방식이 URI와 연관된 의미를 결정하며, 그 의미의 유용성이 궁극적으로 사용자가 참조하고 접근할 수 있는 자원이 됩니다.

스킴, 호스트 또는 포트가 서로 다르면 두 출처는 구별됩니다. 동일한 주체가 두 개의 서로 다른 출처를 제어하는 것으로 확인되더라도, 그 출처들 아래의 두 네임스페이스는 서버가 명시적으로 별칭을 제공하지 않는 한 서로 구별됩니다.

출처는 이 문서의 범위를 벗어나 HTML 및 관련 웹 프로토콜 내에서도 사용되며, 이에 대해서는 [RFC6454]를 참조하십시오.

HTTP는 전송 프로토콜과 독립적이지만, "http" 스킴(섹션 4.2.1 참조)은 표시된 호스트의 해당 포트에서 TCP 연결을 수신하는 출처 서버를 제어하는 주체와 권한을 연관시키는 데 특화되어 있습니다. 이는 클라이언트별 이름 해석 메커니즘과 경로상 공격자로부터 보안되지 않을 수 있는 통신에 의존하기 때문에 매우 약한 권한의 의미입니다. 그럼에도 불구하고 신뢰된 환경 내에서 "http" 식별자를 출처 서버에 바인딩하여 일관되게 해석하는 데 충분한 최소한의 기준입니다.

호스트 식별자가 IP 주소로 제공되면, 출처 서버는 해당 IP 주소의 표시된 TCP 포트에서 청취자(있는 경우)입니다. 호스트가 등록된 이름이면, 등록된 이름은 적절한 출처 서버의 주소를 찾기 위해 DNS와 같은 이름 해석 서비스와 함께 사용되는 간접 식별자입니다.

"http" URI가 표시된 리소스에 접근해야 하는 컨텍스트에서 사용될 때, 클라이언트는 호스트 식별자를 IP 주소로 해석하고, 해당 주소의 표시된 포트로 TCP 연결을 설정한 다음, 해당 연결을 통해 클라이언트의 대상 URI와 일치하는 요청 대상을 포함한 HTTP 요청 메시지를 전송하여 접근을 시도할 수 있습니다 (섹션 7.1 참조).

서버가 그러한 요청에 대해 비중간 응답(non-interim HTTP response message)을 반환하면(섹션 15 참조), 그 응답은 클라이언트 요청에 대한 권한 있는 응답으로 간주됩니다.

그러나 위의 방법이 권한 있는 응답을 얻는 유일한 수단은 아니며, 권한 있는 응답이 항상 필요하다는 것을 의미하지는 않습니다(캐싱 참조). 예를 들어, Alt-Svc 헤더 필드는 출처가 해당 출처에 대해 또한 권한이 있는 다른 서비스를 식별하도록 허용합니다. "http"로 식별된 리소스에 대한 접근은 이 문서의 범위를 벗어난 프로토콜에 의해서도 제공될 수 있습니다.

"https" 스킴(섹션 4.2.2 참조)은 서버가 식별된 출처 서버에 대해 신뢰할 수 있는 것으로 클라이언트가 간주하는 인증서에 대응하는 개인 키를 사용할 수 있는 능력에 기반하여 권한을 연관시킵니다. 클라이언트는 일반적으로 신뢰 앵커에서 전달되는 신뢰 체인을 통해 인증서를 신뢰 가능한 것으로 간주합니다(섹션 4.3.4 참조).

HTTP/1.1 및 이전 버전에서는, 클라이언트는 URI 출처의 호스트에 대해 성공적으로 설정되고 보안된 연결을 통해 통신할 때에만 서버에 권한을 부여합니다. 연결 설정 및 인증서 확인은 권한의 증명으로 사용됩니다.

HTTP/2 및 HTTP/3에서는 클라이언트가 서버의 인증서에 포함된 호스트 중 하나와 URI 출처의 호스트가 일치하고, 클라이언트가 해당 호스트에 대해 연결을 열 수 있다고 믿는 경우, 성공적으로 설정되고 보안된 연결을 통해 통신하고 있을 때 서버에 권한을 부여합니다. 실제로 클라이언트는 기 설정된 연결과 동일한 서버 IP 주소를 가지는지 확인하기 위해 DNS 쿼리를 수행합니다. 이 제한은 출처 서버가 동등한 ORIGIN 프레임을 전송하면 제거될 수 있습니다.

요청 대상의 호스트 및 포트 값은 각 HTTP 요청에 전달되어 출처를 식별하고 동일 서버가 제어할 수 있는 다른 네임스페이스와 구별합니다(섹션 7.2 참조). 출처는 인증서의 개인 키에 대한 제어를 가진 모든 서비스가 동일하게 해당 "https" 네임스페이스를 관리하도록 하거나, 잘못 전달된 것으로 보이는 요청을 거부할 준비가 되어 있어야 합니다(섹션 7.4 참조).

출처 서버는 권한이 있어도 특정 대상 URI에 대한 요청을 처리하기를 꺼릴 수 있습니다. 예를 들어, 호스트가 서로 다른 포트(예: 443 및 8000)에서 별개의 서비스를 운영하는 경우, 연결이 확보된 후에도 대상 URI를 출처 서버에서 확인하는 것이 필요합니다. 네트워크 공격자가 한 포트의 연결을 다른 포트로 전달하게 할 수 있기 때문입니다. 대상 URI를 확인하지 않으면 공격자가 한 대상 URI의 응답을 다른 포트의 것으로 대체할 수 있습니다.

"https" 스킴은 권한을 연관시키기 위해 TCP 및 연결된 포트 번호에 의존하지 않습니다. 이는 둘 다 보안된 통신의 범위를 벗어나므로 최종적으로 신뢰할 수 없기 때문입니다. 따라서 HTTP 통신은 TCP를 사용하지 않는 프로토콜을 포함하여 섹션 4.2.2에 정의된 바와 같이 보안이 확보된 어떤 채널에서든 발생할 수 있습니다.

"https" URI가 표시된 리소스에 접근해야 하는 컨텍스트에서 사용될 때, 클라이언트는 호스트 식별자를 IP 주소로 해석하고, 해당 주소의 표시된 포트로 TCP 연결을 설정하며, TCP 위에서 TLS를 성공적으로 시작하여 종단 간 보안(기밀성 및 무결성 보호)을 확보한 다음, 해당 연결을 통해 클라이언트의 대상 URI와 일치하는 요청 대상을 포함한 HTTP 요청 메시지를 전송하여 접근을 시도할 수 있습니다 (섹션 7.1 참조).

서버가 그러한 요청에 대해 비중간 응답을 반환하면(섹션 15 참조), 그 응답은 클라이언트 요청에 대한 권한 있는 응답으로 간주됩니다.

그러나 위의 방법이 권한 있는 응답을 얻는 유일한 수단은 아니며, 권한 있는 응답이 항상 필요하다는 것을 의미하지는 않습니다(캐싱 참조).

URI를 역참조하기 위해 보안된 연결을 설정하려면, 클라이언트는 서비스의 식별이 URI의 출처 서버에 대해 허용 가능한 일치인지 반드시 검증해야 합니다. 인증서 검증은 경로상 공격자나 이름 해석을 제어하는 공격자가 서버를 사칭하는 것을 방지하는 데 사용됩니다. 이 과정은 클라이언트가 신뢰 앵커 집합으로 구성되어 있어야 합니다.

일반적으로 클라이언트는 섹션 6에 정의된 검증 절차를 사용하여 서비스 식별을 검증해야 합니다. 클라이언트는 서비스의 호스트에서 참조 식별자를 구성해야 합니다: 호스트가 리터럴 IP 주소인 경우(섹션 4.3.5), 참조 식별자는 IP-ID이고, 그렇지 않으면 호스트는 이름이고 참조 식별자는 DNS-ID입니다.

CN-ID 유형의 참조 식별자는 클라이언트에 의해 사용되어서는 안 됩니다. RFC6125 섹션 6.2.1에 언급된 바와 같이, CN-ID 유형의 참조 식별자는 오래된 클라이언트에 의해 사용될 수 있습니다.

클라이언트는 특별히 구성되어 대체 형태의 서버 식별 검증을 허용할 수 있습니다. 예를 들어, 클라이언트가 주소와 호스트 이름이 동적인 서버에 연결하고, 서비스가 대상 URI의 출처와 일치하는 인증서 대신 특정 인증서(또는 외부에서 정의된 참조 식별자와 일치하는 인증서)를 제시할 것으로 기대할 수 있습니다.

특수한 경우에 클라이언트가 단순히 서버의 식별을 무시하는 것이 적절할 수 있지만, 이는 연결을 능동적 공격에 취약하게 남겨둔다는 것을 이해해야 합니다.

인증서가 대상 URI의 출처에 대해 유효하지 않으면, 사용자 에이전트는 진행하기 전에 사용자로부터 확인을 얻어야 한다 (섹션 3.5 참조) 또는 잘못된 인증서 오류로 연결을 종료해야 합니다. 자동화된 클라이언트는 오류를 적절한 감사 로그에 기록해야 하며 (가능한 경우) 연결을 종료하는 것이 권고됨. 자동화된 클라이언트는 이 검사를 비활성화하는 구성 설정을 제공할 수 있지만, 이를 활성화하는 설정을 제공해야 합니다.

"https" URI의 "host" 필드에 IP 주소 리터럴이 사용된 서버는 IP-ID 유형의 참조 식별자를 가집니다. IPv4 주소는 "IPv4address" ABNF 규칙을 사용하고, IPv6 주소는 "IP-literal" 생산 규칙에서 "IPv6address" 옵션을 사용합니다(섹션 3.2.2 참조). IP-ID 유형의 참조 식별자는 IP 주소의 디코드된 바이트를 포함합니다.

IPv4 주소는 4 옥텟이고, IPv6 주소는 16 옥텟입니다. 다른 IP 버전에 대해 IP-ID 사용은 정의되지 않습니다. 인증서 subjectAltName 확장의 iPAddress 선택은 IP 버전을 명시적으로 포함하지 않으므로 주소의 길이에 의존하여 버전을 구별합니다(섹션 4.2.1.6 참조).

IP-ID 유형의 참조 식별자는 주소가 인증서의 subjectAltName 확장의 iPAddress 값과 동일한 경우 일치합니다.

RFC 5234의 ABNF 규칙에 대한 #rule 확장은 일부 리스트 기반 필드 값의 정의에서 가독성을 향상시키기 위해 사용됩니다.

"#" 구성은 요소들의 쉼표로 구분된 목록을 정의하기 위해 "*"와 유사하게 정의됩니다. 전체 형태는 "<n>#<m>element"로, 각 요소는 단일 쉼표(",")와 선택적 공백(OWS, 섹션 5.6.3 정의)으로 구분되며 최소 <n>개, 최대 <m>개 요소를 의미합니다.

토큰은 공백 또는 구분 문자를 포함하지 않는 짧은 텍스트 식별자입니다.

  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; any VCHAR, except delimiters

많은 HTTP 필드 값은 공통 구문 구성요소를 사용하여 정의되며, 이는 공백 또는 특정 구분 문자로 구분됩니다. 구분자는 토큰에서 허용되지 않는 US-ASCII 시각 문자 집합에서 선택됩니다(DQUOTE 및 "(),/:;<=>?@[\]{}").

이 명세서는 선형 공백의 사용을 나타내기 위해 OWS(선택적 공백), RWS(필수 공백) 및 BWS("나쁜" 공백)의 세 규칙을 사용합니다.

OWS 규칙은 0개 이상의 선형 공백 옥텟이 나타날 수 있는 곳에 사용됩니다. 가독성을 높이기 위해 선택적 공백을 생성하는 것이 선호되는 프로토콜 요소의 경우, 발신자는 선택적 공백을 단일 SP로 생성하는 것이 SHOULD 합니다. 그렇지 않으면 발신자는 제자리(in-place) 메시지 필터링 중에 잘못되었거나 원치 않는 프로토콜 요소를 덮어쓰는 데 필요한 경우를 제외하고 선택적 공백을 생성해서는 SHOULD NOT 합니다.

RWS 규칙은 필드 토큰을 구분하기 위해 적어도 하나의 선형 공백 옥텟이 필요한 경우에 사용됩니다. 발신자는 RWS를 단일 SP로 생성하는 것이 SHOULD 합니다.

OWS와 RWS는 단일 SP와 동일한 의미를 갖습니다. OWS 또는 RWS로 정의된 것으로 알려진 모든 내용은 해석하거나 메시지를 하류로 전달하기 전에 단일 SP로 대체될 수 MAY 있습니다.

BWS 규칙은 문법이 역사적 이유로 선택적 공백만 허용하는 곳에 사용됩니다. 발신자는 메시지에서 BWS를 생성해서는 MUST NOT 합니다. 수신자는 그러한 잘못된 공백을 파싱하여 프로토콜 요소를 해석하기 전에 제거해야 MUST 합니다.

BWS는 의미를 갖지 않습니다. BWS로 정의된 것으로 알려진 모든 내용은 해석하거나 메시지를 전달하기 전에 제거될 수 MAY 있습니다.

  OWS            = *( SP / HTAB )
                 ; optional whitespace
  RWS            = 1*( SP / HTAB )
                 ; required whitespace
  BWS            = OWS
                 ; "bad" whitespace

쌍따옴표로 감싸인 경우 텍스트 스트링은 단일 값으로 구문 분석됩니다.

  quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
  qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text

백슬래시 옥텟("\")은 quoted-string 및 comment 구성 내에서 단일 옥텟 인용 메커니즘으로 사용될 수 있습니다. quoted-string의 값을 처리하는 수신자는 quoted-pair를 백슬래시 다음의 옥텟으로 대체된 것으로 처리해야 MUST 합니다.

  quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

발신자는 DQUOTE 및 백슬래시 옥텟을 인용하기 위해 필요한 경우를 제외하고 quoted-string 내에서 quoted-pair를 생성해서는 SHOULD NOT 합니다. 발신자는 코멘트 내에서 괄호 "(" 및 ")" 및 백슬래시 옥텟을 인용하기 위해 필요한 경우를 제외하고 quoted-pair를 생성해서는 SHOULD NOT 합니다.

코멘트는 코멘트 텍스트를 괄호로 둘러싸서 일부 HTTP 필드에 포함될 수 있습니다. 코멘트는 필드 값 정의에 "comment"가 해당 필드 값의 일부로 포함된 필드에서만 허용됩니다.

  comment        = "(" *( ctext / quoted-pair / comment ) ")"
  ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

매개변수는 이름/값 쌍의 인스턴스입니다; 종종 항목에 보조 정보를 덧붙이기 위한 공통 구문으로 필드 값에서 사용됩니다. 각 매개변수는 보통 바로 앞에 오는 세미콜론으로 구분됩니다.

  parameters      = *( OWS ";" OWS [ parameter ] )
  parameter       = parameter-name "=" parameter-value
  parameter-name  = token
  parameter-value = ( token / quoted-string )

매개변수 이름은 대소문자를 구분하지 않습니다. 매개변수 값은 매개변수 이름의 의미에 따라 대소문자를 구분할 수도 있고 그렇지 않을 수도 있습니다. 매개변수의 예와 몇 가지 동등한 형태는 미디어 타입(섹션 8.3.1) 및 Accept 헤더 필드(섹션 12.5.1)에서 볼 수 있습니다.

token 생산 규칙과 일치하는 매개변수 값은 토큰으로 전송되거나 인용 문자열로 전송될 수 있습니다. 인용된 값과 인용되지 않은 값은 동등합니다.

1995년 이전에는 서버들이 타임스탬프를 전달하기 위해 일반적으로 사용하던 세 가지 형식이 있었습니다. 오래된 구현체와의 호환성을 위해 세 가지 형식 모두가 여기에서 정의됩니다. 선호되는 형식은 Internet Message Format([RFC5322])에서 사용되는 날짜 및 시간 명세의 고정 길이 단일 영역(zone) 부분집합입니다.

  HTTP-date    = IMF-fixdate / obs-date

선호되는 형식의 예는 다음과 같습니다

Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

두 가지 오래된 형식의 예는 다음과 같습니다

Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

HTTP 필드에서 타임스탬프 값을 파싱하는 수신자는 세 가지 HTTP-date 형식 모두를 수용해야 MUST 합니다. 발신자가 하나 이상의 HTTP-date로 정의된 타임스탬프를 포함하는 필드를 생성할 때, 발신자는 해당 타임스탬프를 IMF-fixdate 형식으로 생성해야 MUST 합니다.

HTTP-date 값은 협정 세계시(UTC)의 인스턴스로 시간을 나타냅니다. 처음 두 형식은 "GMT"라는 세 글자 약어로 UTC를 나타내며, asctime 형식의 값은 UTC로 가정됩니다.

시계(clock)는 UTC의 현재 순간을 합리적으로 근사할 수 있는 구현체입니다. 시계 구현체는 NTP([RFC5905]) 또는 유사한 프로토콜을 사용하여 UTC와 동기화하는 것이 바람직합니다.

  IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  ; fixed length/zone/capitalization subset of the format
  ; see Section 3.3 of [RFC5322]

  day-name     = %s"Mon" / %s"Tue" / %s"Wed"
               / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"

  date1        = day SP month SP year
               ; e.g., 02 Jun 1982

  day          = 2DIGIT
  month        = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
               / %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
               / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
  year         = 4DIGIT

  GMT          = %s"GMT"

  time-of-day  = hour ":" minute ":" second
               ; 00:00:00 - 23:59:60 (leap second)

  hour         = 2DIGIT
  minute       = 2DIGIT
  second       = 2DIGIT

  obs-date     = rfc850-date / asctime-date

  rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
  date2        = day "-" month "-" 2DIGIT
               ; e.g., 02-Jun-82

  day-name-l   = %s"Monday" / %s"Tuesday" / %s"Wednesday"
               / %s"Thursday" / %s"Friday" / %s"Saturday"
               / %s"Sunday"

  asctime-date = day-name SP date3 SP time-of-day SP year
  date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
               ; e.g., Jun  2

HTTP-date는 대소문자를 구분합니다. 캐시 수신자에 대해서는 섹션 4.2가 이를 완화한다는 점에 유의하십시오(참조: [CACHING]).

발신자는 문법에서 명시적으로 포함된 SP 이외의 추가 공백을 HTTP-date에 생성해서는 MUST NOT 합니다. day-name, day, month, year, 및 time-of-day의 의미는 해당 이름을 가진 Internet Message Format 구성과 동일합니다([RFC5322], Section 3.3 참조).

두 자리 연도를 사용하는 rfc850-date 형식의 타임스탬프 값을 수신하는 수신자는, 해당 값이 향후 50년보다 더 미래로 보이는 경우 가장 최근 과거 중 동일한 마지막 두 숫자를 가진 연도로 해석해야 MUST 합니다.

타임스탬프 값을 수신하는 수신자는 필드 정의에서 달리 제한하지 않는 한 파싱에 있어 강인성을 유지하도록 권장됩니다. 예를 들어, 메시지는 가끔 비-HTTP 원본에서 HTTP로 전달되며, 그 원본은 Internet Message Format에서 정의된 어떤 날짜 및 시간 표기법도 생성할 수 있습니다.

요청의 콘텐츠 목적은 메서드 의미(섹션 9)에 의해 정의됩니다.

예를 들어, PUT 요청의 콘텐츠에 있는 표현(섹션 9.3.4)은 요청이 성공적으로 적용된 이후의 대상 리소스의 원하는 상태를 나타내고, POST 요청의 콘텐츠에 있는 표현(섹션 9.3.3)은 대상 리소스가 처리할 정보를 나타냅니다.

응답에서 콘텐츠의 목적은 요청 메서드, 응답 상태 코드(섹션 15) 및 그 콘텐츠를 설명하는 응답 필드에 의해 정의됩니다. 예를 들어, GET에 대한 200 (OK) 응답의 콘텐츠는 메시지 생성 시점(섹션 6.6.1)에 관찰된 대상 리소스의 현재 상태를 나타내는 반면, 동일한 상태 코드의 POST에 대한 응답에서의 콘텐츠는 처리 결과 또는 처리를 적용한 이후의 대상 리소스의 새 상태를 나타낼 수 있습니다.

206 (Partial Content) 응답의 콘텐츠는 GET에 대해 선택된 표현의 단일 부분이거나 그 표현의 여러 부분을 포함하는 multipart 메시지 본문을 포함합니다(섹션 15.3.7 참조).

오류 상태 코드를 가진 응답 메시지는 일반적으로 오류 상태를 나타내는 콘텐츠를 포함하며, 그 콘텐츠는 오류 상태와 이를 해결하기 위해 권장되는 단계를 설명합니다.

HEAD 요청 메서드에 대한 응답은 결코 콘텐츠를 포함하지 않습니다; 관련 응답 헤더 필드는 요청 메서드가 GET이었다면 그 값이 무엇이 되었을지를 나타내기만 합니다(섹션 9.3.1).

2xx (Successful) 응답 중 CONNECT 요청 메서드(섹션 9.3.6에 대한 응답)는 콘텐츠 대신 연결을 터널 모드로 전환합니다.

모든 1xx (Informational), 204 (No Content), 및 304 (Not Modified) 응답은 콘텐츠를 포함하지 않습니다.

그 외의 모든 응답은 콘텐츠를 포함하지만, 그 콘텐츠의 길이가 0일 수 있습니다.

완전하거나 부분적인 표현이 메시지 콘텐츠로 전송될 때, 송신자가 해당 특정 표현에 해당하는 리소스의 식별자를 제공하거나 수신자가 이를 결정하는 것이 종종 바람직합니다. 예를 들어, "현재 기상 보고" 리소스에 대해 GET 요청을 하는 클라이언트는 반환된 콘텐츠에 특정한 식별자(예: "20210720T1711의 Laguna Beach 기상 보고")를 원할 수 있습니다. 이는 시간이 지남에 따라 표현이 변경될 것으로 예상되는 리소스에서 콘텐츠를 공유하거나 북마크하는 데 유용할 수 있습니다.

• 요청에 Content-Location 헤더 필드가 있는 경우, 송신자는 콘텐츠가 Content-Location 필드 값으로 식별된 리소스의 표현임을 주장합니다. 다만 그러한 주장은 이 명세서에서 정의하지 않는 다른 수단으로 검증되지 않는 한 신뢰할 수 없습니다. 그 정보는 개정 이력 링크에 유용할 수 있습니다.
• 그렇지 않으면 콘텐츠는 HTTP에 의해 식별되지 않으며, 더 구체적인 식별자는 콘텐츠 자체 내에 제공될 수 있습니다.

1. 요청 메서드가 HEAD이거나 응답 상태 코드가 204 (No Content) 또는 304 (Not Modified)이면 응답에 콘텐츠가 없습니다.
2. 요청 메서드가 GET이고 응답 상태 코드가 200 (OK)이면, 콘텐츠는 대상 리소스의 표현입니다(섹션 7.1 참조).
3. 요청 메서드가 GET이고 응답 상태 코드가 203 (Non-Authoritative Information)이면, 콘텐츠는 중개자가 제공하는 대상 리소스의 잠재적으로 수정되거나 향상된 표현일 수 있습니다.
4. 요청 메서드가 GET이고 응답 상태 코드가 206 (Partial Content)이면, 콘텐츠는 대상 리소스의 표현의 하나 이상의 부분입니다.
5. 응답에 Content-Location 헤더 필드가 있고 그 필드 값이 대상 URI와 동일한 URI에 대한 참조이면, 콘텐츠는 대상 리소스의 표현입니다.
6. 응답에 Content-Location 헤더 필드가 있고 그 필드 값이 대상 URI와 다른 URI에 대한 참조이면, 송신자는 콘텐츠가 Content-Location 필드 값으로 식별된 리소스의 표현임을 주장합니다. 다만 그러한 주장은 이 명세서에서 정의하지 않는 다른 수단으로 검증되지 않는 한 신뢰할 수 없습니다.
7. 그렇지 않으면 콘텐츠는 HTTP에 의해 식별되지 않지만, 더 구체적인 식별자가 콘텐츠 자체 내에 제공될 수 있습니다.

트레일러 섹션은 사용 중인 HTTP 버전이 이를 지원하고 명시적 프레이밍 메커니즘으로 활성화된 경우에만 가능합니다. 예를 들어, HTTP/1.1의 chunked 전송 인코딩은 콘텐츠 이후에 트레일러 섹션을 보낼 수 있게 합니다(Section 7.1.2 of [HTTP/1.1]).

많은 필드는 프레이밍, 라우팅, 인증, 요청 수정자, 응답 제어 또는 콘텐츠 형식을 설명하는 등 콘텐츠를 받기 전에 평가되어야 하기 때문에 헤더 섹션 외부에서 처리될 수 없습니다. 송신자는 해당 헤더 필드 이름의 정의가 트레일러에서 전송되는 것을 허용하지 않는 한 트레일러 필드를 생성해서는 MUST NOT 합니다.

트레일러 필드는 한 프로토콜 버전에서 다른 버전으로 메시지를 전달하는 중개자에 의해 처리하기 어려울 수 있습니다. 전체 메시지를 전송 중에 버퍼링할 수 있다면 일부 중개자는 트레일러 필드를 적절한 경우 헤더 섹션에 병합한 다음 전달할 수 있습니다. 그러나 대부분의 경우 트레일러는 단순히 폐기됩니다. 수신자는 해당 헤더 필드 정의를 이해하고 그 정의가 명시적으로 트레일러 필드 값을 안전하게 병합하는 방법을 허용하고 정의하지 않는 한 트레일러 필드를 헤더 섹션에 병합해서는 MUST NOT 합니다.

요청의 TE 헤더 필드(섹션 10.1.4)에 "trailers" 키워드가 있는 것은 클라이언트가 자신과 모든 하류 클라이언트를 대신하여 트레일러 필드를 수락할 의사가 있음을 나타냅니다. 중개자로부터 오는 요청의 경우, 이는 모든 하류 클라이언트가 전달된 응답에서 트레일러 필드를 수락할 의사가 있음을 의미합니다. "trailers"의 존재가 클라이언트가 응답의 특정 트레일러 필드를 처리할 것임을 의미하지는 않습니다; 단지 트레일러 섹션이 어떤 클라이언트에 의해서도 삭제되지 않을 것임을 의미합니다.

트레일러 필드가 전송 중에 폐기될 가능성 때문에, 서버는 사용자 에이전트가 수신해야 한다고 믿는 트레일러 필드를 생성해서는 SHOULD NOT 합니다.

송신자가 트레일러 섹션에서 보낼 가능성이 있는 필드 이름의 목록을 나타내기 위해 "Trailer" 헤더 필드(섹션 6.6.2)를 보낼 수 있으며, 이는 수신자가 콘텐츠를 처리하기 전에 해당 메타데이터 수신을 준비할 수 있게 합니다. 예를 들어, 필드 이름이 동적 체크섬이 콘텐츠를 수신하는 동안 계산되어 트레일러 필드 값이 수신되면 즉시 확인되어야 함을 나타낼 수 있습니다.

헤더 필드와 마찬가지로 동일한 이름을 가진 트레일러 필드는 수신된 순서대로 처리됩니다; 동일한 이름을 가진 여러 트레일러 필드 라인은 여러 값을 멤버 목록으로 추가하는 것과 동등한 의미를 가집니다. 메시지 도중 여러 번 생성될 수 있는 트레일러 필드는 각 필드 라인당 멤버 값이 한 번만 처리되더라도 리스트 기반 필드로 정의되어야 MUST 합니다.

메시지 끝에서 수신자는 수신된 트레일러 필드 집합을 헤더 필드와 유사한(그러나 별개의) 이름/값 쌍의 자료 구조로 처리할 수 MAY 있습니다. 트레일러에 사용하기 위한 필드의 명세 내에서 추가 처리 기대사항이 정의될 수 있습니다.

"Date" 헤더 필드는 메시지가 생성된 날짜와 시간을 나타내며, Internet Message Format의 Origination Date Field(orig-date)와 동일한 의미를 가집니다(관련 내용은 Section 3.6.1 참조). 필드 값은 섹션 5.6.7에 정의된 HTTP-date입니다.

  Date = HTTP-date

예시는 다음과 같습니다

Date: Tue, 15 Nov 1994 08:12:31 GMT

Date 헤더 필드를 생성하는 송신자는 메시지 생성 시각의 가능한 최선의 근사값을 필드 값으로 생성하는 것이 SHOULD 합니다. 이론적으로 날짜는 메시지 콘텐츠를 생성하기 직전의 순간을 나타내야 합니다. 실무에서는 송신자가 메시지 생성 중 어느 시점에서든 날짜 값을 생성할 수 있습니다.

시계(clock)가 있는(origin server with a clock) 출처 서버는 모든 2xx (Successful), 3xx (Redirection) 및 4xx (Client Error) 응답에서 Date 헤더 필드를 생성해야 MUST 하며, 1xx (Informational) 및 5xx (Server Error) 응답에서는 선택적으로(Date 헤더를) 생성할 수 MAY 있습니다.

시계가 없는 출처 서버(origin server without a clock)는 Date 헤더 필드를 생성해서는 MUST NOT 합니다.

시계가 있는 수신자는 Date 헤더 필드가 없는 응답 메시지를 수신하면 수신된 시간을 기록하고 그 메시지가 캐시되거나 하류로 전달되는 경우 해당 메시지의 헤더 섹션에 상응하는 Date 헤더 필드를 추가해야 MUST 합니다.

시계가 있는 수신자가 잘못된 Date 헤더 필드 값을 가진 응답을 수신하면, 그 수신자는 해당 값을 응답이 수신된 시간으로 대체할 수 MAY 있습니다.

사용자 에이전트는 요청에 Date 헤더 필드를 보낼 수 MAY 있지만, 일반적으로 서버에 유용한 정보를 전달한다고 판단되지 않는 한 그러지 않습니다. 예를 들어, 맞춤형 HTTP 애플리케이션은 사용자 에이전트와 서버 시계 간의 차이에 따라 서버가 사용자의 요청 해석을 조정할 것으로 예상되는 경우 Date를 전달할 수 있습니다.

"Trailer" 헤더 필드는 송신자가 해당 메시지의 트레일러 필드로 보낼 것으로 예상하는 필드 이름의 목록을 제공합니다. 이는 수신자가 콘텐츠 처리를 시작하기 전에 표시된 메타데이터의 수신을 준비할 수 있게 합니다.

  Trailer = #field-name

예를 들어, 송신자가 콘텐츠를 스트리밍하는 동안 서명을 계산하고 최종 서명을 트레일러 필드로 제공할 수 있음을 나타낼 수 있습니다. 이는 수신자가 콘텐츠를 수신하는 동안 동일한 검사를 즉시 수행할 수 있게 합니다.

메시지에 하나 이상의 트레일러 필드를 생성하려는 송신자는 그 메시지의 헤더 섹션에 Trailer 헤더 필드를 생성하여 트레일러에 어떤 필드가 있을 수 있는지를 표시하는 것이 SHOULD 합니다.

중개자가 전송 중에 트레일러 섹션을 폐기하는 경우, Trailer 필드는 어떤 메타데이터가 손실되었는지에 대한 힌트를 제공할 수 있지만, Trailer를 보낸 송신자가 항상 명시된 필드를 전송할 것이라고 보장되지는 않습니다.

클라이언트에 캐시([CACHING])가 있고 요청이 캐시로 만족될 수 있다면, 일반적으로 요청은 먼저 캐시로 향합니다.

요청이 캐시로 만족되지 않으면, 일반적인 클라이언트는 요청을 만족시키기 위해 프록시를 사용해야 하는지 구성에서 확인합니다. 프록시 구성은 구현에 따라 다르지만, 종종 URI 접두사 매칭, 선택적 권한(authority) 매칭 또는 둘 모두에 기반하며, 프록시는 보통 "http" 또는 "https" URI로 식별됩니다.

"http" 또는 "https" 프록시가 적용 가능한 경우, 클라이언트는 해당 프록시에 대한 연결을 설정(또는 재사용)한 다음 클라이언트의 대상 URI와 일치하는 요청 대상을 포함한 HTTP 요청 메시지를 그 프록시로 전송합니다.

적용 가능한 프록시가 없으면, 일반적인 클라이언트는 대상 URI의 스킴에 특화된 핸들러 루틴을 호출하여 식별된 리소스에 접근합니다. 해당 방식은 대상 URI 스킴에 따라 달라지며 관련 명세에서 정의됩니다.

섹션 4.3.2는 식별된 출처의 origin 서버에 대한(또는 재사용된) 인바운드 연결을 설정한 다음, 클라이언트의 대상 URI와 일치하는 요청 대상을 포함한 HTTP 요청 메시지를 전송함으로써 "http" 리소스에 접근하는 방법을 정의합니다.

섹션 4.3.3은 식별된 출처에 권한이 있는 origin 서버와의 인바운드 보안 연결을 설정(또는 재사용)한 다음, 클라이언트의 대상 URI와 일치하는 요청 대상을 포함한 HTTP 요청 메시지를 전송함으로써 "https" 리소스에 접근하는 방법을 정의합니다.

"Connection" 헤더 필드는 송신자가 현재 연결에 대해 원하는 제어 옵션을 나열할 수 있게 합니다.

  Connection        = #connection-option
  connection-option = token

Connection 옵션은 대소문자를 구분하지 않습니다.

Connection 이외의 필드가 현재 연결에 대한 제어 정보를 제공하는 데 사용될 때, 송신자는 해당 필드 이름을 Connection 헤더 필드에 나열해야 MUST 합니다. 일부 HTTP 버전은 그러한 정보를 위한 필드 사용을 금지하므로 Connection 필드를 허용하지 않는다는 점에 유의하십시오.

중개자는 메시지를 전달하기 전에 수신된 Connection 헤더 필드를 파싱해야 하며, 이 필드의 각 connection-option에 대해 해당 connection-option과 동일한 이름을 가진 모든 헤더 또는 트레일러 필드를 메시지에서 제거한 다음 Connection 헤더 필드 자체를 제거해야 MUST 합니다(또는 전달된 메시지에 대한 중개자의 자체 제어 옵션으로 대체할 수 있습니다).

따라서 Connection 헤더 필드는 즉시 수신자("hop-by-hop")에만 의도된 필드와 체인상의 모든 수신자("end-to-end")를 위한 필드를 선언적으로 구분하는 방법을 제공하여, 메시지가 자기 설명적이 되게 하고 향후 연결 특정 확장이 오래된 중개자에 의해 맹목적으로 전달될 것이라는 두려움 없이 배포될 수 있게 합니다.

• Proxy-Connection (Appendix C.2.2 of [HTTP/1.1])
• Keep-Alive (Section 19.7.1 of [RFC2068])
• TE (섹션 10.1.4)
• Transfer-Encoding (섹션 6.1 of [HTTP/1.1])
• Upgrade (섹션 7.8)

송신자는 콘텐츠의 모든 수신자에게 의도된 필드에 해당하는 connection option을 전송해서는 안 됩니다. 예를 들어 Cache-Control은 connection option으로 절대 적절하지 않습니다(자세한 내용은 섹션 5.2 of [CACHING] 참조).

Connection 옵션은 연결 특정 필드에 매개변수가 없으면 메시지에 존재하는 필드에 항상 해당하지 않을 수 있습니다. 반대로, 연결 옵션에 해당하는 항목 없이 수신된 연결 특정 필드는 보통 중개자가 잘못 전달했음을 나타내며 수신자는 해당 필드를 무시해야 합니다.

필드에 해당하지 않는 새로운 connection option을 정의할 때, 명세 작성자는 이후 충돌을 피하기 위해 해당 필드 이름을 어쨌든 예약해야 합니다. 이러한 예약된 필드 이름은 "Hypertext Transfer Protocol (HTTP) Field Name Registry"(섹션 16.3.1)에 등록됩니다.

"Max-Forwards" 헤더 필드는 TRACE(섹션 9.3.8) 및 OPTIONS(섹션 9.3.7) 요청 메서드와 함께 프록시가 요청을 전달하는 횟수를 제한하는 메커니즘을 제공합니다. 이는 클라이언트가 중간 체인에서 실패하거나 루프하는 것처럼 보이는 요청을 추적하려 할 때 유용할 수 있습니다.

  Max-Forwards = 1*DIGIT

Max-Forwards 값은 이 요청 메시지가 남은 전달 가능 횟수를 나타내는 10진 정수입니다.

TRACE 또는 OPTIONS 요청을 수신한 각 중개자는 전달하기 전에 Max-Forwards 값을 확인하고 업데이트해야 MUST 합니다. 수신된 값이 0이면 중개자는 요청을 전달해서는 안 됩니다; 대신 중개자는 최종 수신자로서 응답해야 MUST 합니다. 수신된 Max-Forwards 값이 0보다 크면, 중개자는 전달된 메시지에서 업데이트된 Max-Forwards 필드를 생성해야 하며 그 필드 값은 a) 수신된 값에서 1을 뺀 값 또는 b) 수신자의 Max-Forwards에 대한 최대 지원 값 중 더 작은 값입니다.

수신자는 다른 요청 메서드로 수신된 Max-Forwards 헤더 필드를 무시할 수 MAY 있습니다.

"Via" 헤더 필드는 이메일의 "Received" 헤더 필드와 유사하게(섹션 3.6.7 of [RFC5322]), 사용자 에이전트와 서버 사이(요청의 경우) 또는 출처 서버와 클라이언트 사이(응답의 경우)에 존재하는 중간 프로토콜 및 수신자를 나타냅니다. Via는 메시지 전달 추적, 요청 루프 회피 및 요청/응답 체인상의 송신자 프로토콜 능력 식별에 사용될 수 있습니다.

  Via = #( received-protocol RWS received-by [ RWS comment ] )

  received-protocol = [ protocol-name "/" ] protocol-version
                    ; see Section 7.8
  received-by       = pseudonym [ ":" port ]
  pseudonym         = token

Via 필드 값의 각 멤버는 메시지를 전달한 프록시나 게이트웨이를 나타냅니다. 각 중개자는 메시지를 수신한 방식에 대한 자신의 정보를 덧붙이며, 최종 결과는 전달 수신자의 순서에 따라 정렬됩니다.

프록시는 전달하는 각 메시지에 대해 아래에 설명된 적절한 Via 헤더 필드를 전송해야 MUST 합니다. HTTP-대-HTTP 게이트웨이는 수신된 각 요청 메시지에 대해 적절한 Via 헤더 필드를 전송해야 MUST 하며, 전달된 응답 메시지에 대해서는 Via 헤더 필드를 전송할 수 MAY 있습니다.

각 중개자에 대해 received-protocol은 상류 송신자가 사용한 프로토콜 및 프로토콜 버전을 나타냅니다. 따라서 Via 필드 값은 요청/응답 체인이 광고한 프로토콜 능력을 기록하여 하류 수신자가 이를 볼 수 있게 하며, 이는 응답에서 또는 이후 요청 내에서 어떤 하위 호환성 없는 기능을 사용하는 것이 안전한지 결정하는 데 유용할 수 있습니다. 간결함을 위해 received-protocol이 HTTP일 때 protocol-name은 생략됩니다.

received-by 부분은 일반적으로 메시지를 이후에 전달한 수신자 서버 또는 클라이언트의 호스트와 선택적 포트 번호입니다. 그러나 실제 호스트가 민감한 정보로 간주되면, 송신자는 이를 의사명(pseudonym)으로 대체할 수 MAY 있습니다. 포트가 제공되지 않은 경우, 수신자는 (있다면) received-protocol의 기본 포트에서 수신되었다고 해석할 수 MAY 있습니다.

송신자는 각 수신자의 소프트웨어를 식별하기 위한 주석을 생성할 수 MAY 있습니다. 이는 User-Agent 및 Server 헤더 필드와 유사합니다. 그러나 Via의 주석은 선택 사항이며, 수신자는 전달하기 전에 이를 제거할 수 MAY 있습니다.

Via: 1.0 fred, 1.1 p.example.net

네트워크 방화벽을 통한 포털로 사용되는 중개자는 방화벽 내부의 호스트 이름 및 포트를 전달해서는 안 됩니다 (명시적으로 허용된 경우 제외). 허용되지 않은 경우, 그러한 중개자는 방화벽 뒤의 호스트들에 대해 수신된 각 received-by 호스트를 적절한 의사명으로 대체해야 SHOULD 합니다.

중개자는 동일한 received-protocol 값을 가진 Via 헤더 필드 목록의 정렬된 부분 시퀀스를 단일 멤버로 결합할 수 MAY 있습니다. 예를 들어,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

는 다음과 같이 축약될 수 있습니다

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

송신자는 모든 리스트 멤버가 동일한 조직적 통제 하에 있고 호스트들이 이미 의사명으로 교체된 경우를 제외하고는 멤버들을 결합해서는 안 됩니다. 송신자는 received-protocol 값이 다른 멤버들을 결합해서는 안 됩니다.

HTTP는 [RFC2046]에 정의된 미디어 타입을 Content-Type 및 Accept 헤더 필드에서 사용하여 개방적이고 확장 가능한 데이터 타입 및 타입 협상 기능을 제공합니다. 미디어 타입은 데이터 형식과 다양한 처리 모델, 즉 메시지 문맥에 따라 해당 데이터를 어떻게 처리할지를 정의합니다.

  media-type = type "/" subtype parameters
  type       = token
  subtype    = token

type과 subtype 토큰은 대소문자 구분이 없습니다.

type/subtype 뒤에 세미콜론으로 구분된 파라미터(섹션 5.6.6)가 name/value 쌍의 형태로 올 수 있습니다. 파라미터의 존재 여부는 미디어 타입 레지스트리 내 정의에 따라 처리에 중요할 수 있습니다. 파라미터 값은 그 이름의 의미에 따라 대소문자 구분이 있을 수도 있고 없을 수도 있습니다.

  text/html;charset=utf-8
  Text/HTML;Charset="utf-8"
  text/html; charset="utf-8"
  text/html;charset=UTF-8

미디어 타입은 IANA에 등록되어야 하며 그 절차는 [BCP13]에 정의되어 있습니다.

HTTP는 텍스트 표현의 문자 인코딩 체계를 지시하거나 협상하기 위해 charset 이름을 사용합니다. 이 문서에서 정의된 필드들에서는 charset 이름이 파라미터(Content-Type)로 나타나거나, 혹은 Accept-Encoding의 경우 평범한 token 형식으로 나타납니다. 두 경우 모두 charset 이름은 대소문자 구분 없이 매치됩니다.

Charset 이름은 IANA의 "Character Sets" 레지스트리에 등록되어야 하며 관련 절차는 [RFC2978]에 정의되어 있습니다.

MIME은 하나의 메시지 본문 내에 하나 이상의 표현을 캡슐화하는 여러 "multipart" 타입을 제공합니다. 모든 multipart 타입은 공통 문법을 공유하며(Section 5.1.1 참조), 미디어 타입 값의 일부로 boundary 파라미터를 포함합니다. 메시지 본문은 자체적으로 프로토콜 요소이며; 발신자는 바디 파트 사이의 줄바꿈을 나타내기 위해 CRLF만 생성해야 MUST 합니다.

HTTP 메시지 프레이밍은 multipart 경계(boundary)를 메시지 본문 길이의 표시로 사용하지 않지만, 콘텐츠를 생성하거나 처리하는 구현에서 이를 사용할 수 있습니다. 예를 들어, "multipart/form-data" 타입은 요청에서 폼 데이터를 전송하는 데 자주 사용되며([RFC7578] 참조), "multipart/byteranges" 타입은 일부 206 (Partial Content) 응답에서 사용하기 위해 이 명세에서 정의되어 있습니다.

Content coding 값은 표현에 적용되었거나 적용될 수 있는 인코딩 변환을 나타냅니다. 콘텐츠 코딩은 표현을 압축하거나 유용하게 변환하여 기본 미디어 타입의 정체성을 잃지 않도록 하는 데 주로 사용됩니다. 종종 표현은 코딩된 형태로 저장되고 전송되며 최종 수신자만이 디코딩합니다.

  content-coding   = token

모든 콘텐츠 코딩은 대소문자 구분이 없으며 "HTTP Content Coding Registry"에 등록되어야 합니다(섹션 16.6 참조).

Content-coding 값은 Accept-Encoding 및 Content-Encoding 헤더 필드에서 사용됩니다.

언어 태그는 [RFC5646]에 정의된 대로, 인간이 정보를 전달하기 위해 사용하는 자연어를 식별합니다. 컴퓨터 언어는 명시적으로 제외됩니다.

HTTP는 Accept-Language 및 Content-Language 헤더 필드 내에서 언어 태그를 사용합니다. Accept-Language는 더 넓은 language-range 생산을 사용하고, Content-Language는 아래에 정의된 language-tag 생산을 사용합니다.

  language-tag = <Language-Tag, see [RFC5646], Section 2.1>

  fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

자세한 정보는 [RFC5646]을 참조하십시오.

밸리데이터는 강하거나 약한 두 가지 유형이 있습니다. 약한 밸리데이터는 생성하기 쉽지만 비교에 있어 덜 유용합니다. 강한 밸리데이터는 비교에 이상적이지만 효율적으로 생성하기 매우 어렵거나 불가능할 수 있습니다. 모든 자원에 동일한 강도의 밸리데이터를 강요하기보다는, HTTP는 사용 중인 밸리데이터 유형을 노출하고 약한 밸리데이터를 전제로 사용할 때의 제한을 부과합니다.

강한 밸리데이터는 GET에 대한 200 (OK) 응답의 콘텐츠에서 관찰 가능한 표현 데이터에 변경이 일어날 때마다 값이 변경되는 표현 메타데이터입니다.

강한 밸리데이터는 표현 데이터 변경 외의 이유(예: 의미상 중요한 표현 메타데이터 변경)가 있어도 변경될 수 있지만, 출처 서버는 원격 캐시 및 저작 도구가 저장한 응답을 무효화해야 할 때만 값을 변경하는 것이 바람직합니다.

캐시 항목은 만료 시간과 관계없이 임의의 기간 동안 지속될 수 있으므로, 캐시는 오래전에 얻은 밸리데이터로 항목을 검증하려고 할 수 있습니다. 강한 밸리데이터는 특정 리소스에 연결된 모든 표현 버전 전반에 대해 고유해야 합니다. 다만 서로 다른 리소스의 표현 간에는 고유성을 보장하지 않습니다.

실무에서 사용되는 다양한 강한 밸리데이터가 있습니다. 최선의 방법은 각 변경마다 고유한 노드 이름과 수정 식별자를 할당하는 엄격한 버전 관리 기반입니다. 표현 데이터에 대한 충돌 저항 해시를 사용하는 것도 충분할 수 있습니다(응답 헤더가 전송되기 전에 데이터가 사용 가능하고, 검증 요청마다 재계산할 필요가 없는 경우). 단, 동일한 데이터 형식을 공유하지만 메타데이터가 다른 동시 표현이 있는 경우 출처 서버는 그런 표현들을 구분하기 위해 밸리데이터에 추가 정보를 포함해야 합니다.

대조적으로, 약한 밸리데이터는 표현 데이터의 모든 변경마다 값이 바뀌지 않을 수 있습니다. 이 약함은 값 계산 방식의 한계(예: 시계 해상도), 모든 가능한 표현에 대해 고유성을 보장할 수 없음, 또는 리소스 소유자가 표현들을 자체적으로 동치로 묶고자 하는 경우 등 때문일 수 있습니다.

출처 서버는 이전 표현이 현재 표현의 대체물로서 부적절하다고 간주될 때 약한 엔터티 태그를 변경해야 SHOULD 합니다. 즉, 출처 서버는 캐시가 오래된 응답을 무효화하도록 원할 때 약한 엔터티 태그를 변경해야 합니다.

예를 들어, 초단위로 콘텐츠가 변경되는 기상 보고서의 표현은 출처 서버 관점에서 동등한 표현 집합으로 그룹화되어 동일한 약한 밸리데이터를 가질 수 있으며, 이는 캐시된 표현이 합리적인 기간 동안 유효하도록 허용할 수 있습니다.

또한 밸리데이터가 동일한 리소스의 둘 이상의 표현에 동시에 공유되는 경우(그 표현들이 동일한 표현 데이터가 아닌 한) 그 밸리데이터는 약한 것으로 간주됩니다. 예를 들어, gzip 코딩이 적용된 표현과 적용되지 않은 표현에 대해 동일한 밸리데이터를 보낸다면 그 밸리데이터는 약합니다. 반면, 표현 메타데이터만 다른 두 동시 표현이 동일한 강한 밸리데이터를 가질 수는 있습니다.

강한 밸리데이터는 캐시 검증, 범위 요청, "lost update" 회피 등 모든 조건 요청에 사용할 수 있습니다. 약한 밸리데이터는 클라이언트가 이전에 얻은 표현 데이터와의 정확한 동일성을 요구하지 않을 때만 사용 가능합니다.

응답의 "Last-Modified" 헤더 필드는 출처 서버가 선택된 표현이 마지막으로 수정되었다고 믿는 날짜 및 시간을 타임스탬프로 제공합니다(요청 처리 종료 시 기준).

  Last-Modified = HTTP-date

사용 예:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

응답의 "ETag" 필드는 요청 처리 종료 시 결정된 선택된 표현에 대한 현재 엔터티 태그를 제공합니다. 엔터티 태그는 동일 리소스의 여러 표현을 구별하기 위한 불투명한 밸리데이터로, 시간 경과에 따른 상태 변화, 콘텐츠 협상으로 인해 동일 시점에 복수 표현이 유효한 경우 등 다양한 경우에 사용됩니다. 엔터티 태그는 약점 표시가 접두된 불투명한 인용 문자열로 구성됩니다.

  ETag       = entity-tag

  entity-tag = [ weak ] opaque-tag
  weak       = %s"W/"
  opaque-tag = DQUOTE *etagc DQUOTE
  etagc      = %x21 / %x23-7E / obs-text
             ; VCHAR except double quotes, plus obs-text

엔터티 태그는 수정 날짜보다 검증에 더 신뢰할 수 있는 경우가 있습니다(예: 수정 날짜 저장이 불편하거나 초 해상도가 충분치 않은 경우).

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

엔터티 태그는 약하거나 강한 밸리데이터일 수 있으며 기본값은 강한 것입니다. 만약 출처 서버가 엔터티 태그를 제공했지만 그것이 강한 밸리데이터의 특성을 모두 만족하지 못한다면, 출처 서버는 불투명 값 앞에 "W/" 접두어를 붙여 그 태그를 약한 것으로 표시해야 MUST 합니다.

발신자는 ETag 필드를 트레일러 섹션에서 보낼 수 MAY 있습니다(섹션 6.5 참조). 그러나 트레일러는 종종 무시되므로, 엔터티 태그가 콘텐츠 전송 중 생성되는 경우를 제외하고는 헤더 필드로 보내는 것이 바람직합니다.

요청 메서드는 정의된 의미가 본질적으로 읽기 전용인 경우 safe로 간주됩니다. 즉, 클라이언트는 안전한 메서드를 적용한 결과로 출처 서버의 상태 변경을 요청하거나 기대하지 않습니다. 또한 안전한 메서드를 합리적으로 사용하는 것은 출처 서버에 손해, 재산 손실 또는 비정상적인 부담을 초래할 것으로 예상되지 않습니다.

안전한 메서드 정의가 구현에 의해 잠재적으로 해롭거나 완전히 읽기 전용이 아니거나 부작용을 일으키는 동작을 포함하는 것을 금지하지는 않습니다. 중요한 점은 클라이언트가 그러한 추가 동작을 요청하지 않았으며 그에 대해 책임을 지지 않는다는 것입니다. 예를 들어, 대부분의 서버는 모든 응답 완료 시 요청 정보를 액세스 로그에 추가하며, 이는 메서드와 관계없이 로그 저장이 가득 차 서버 실패를 일으킬 수 있지만 안전하다고 간주됩니다. 또한 웹에서 광고를 선택하여 시작된 안전한 요청은 광고 계정에 과금되는 부작용을 가질 수 있습니다.

이 명세서에서 정의된 요청 메서드 중 GET, HEAD, OPTIONS, 및 TRACE 메서드는 안전하도록 정의되어 있습니다.

안전한 메서드와 비안전 메서드를 구분하는 목적은 스파이더와 같은 자동 검색 프로세스 및 캐시 성능 최적화(프리페칭)가 해를 끼칠 우려 없이 동작하도록 하기 위함입니다. 또한 사용자 에이전트가 신뢰할 수 없는 콘텐츠를 처리할 때 비안전 메서드의 자동 사용에 적절한 제약을 적용할 수 있게 합니다.

사용자 에이전트는 사용자가 잠재적 동작을 표시할 때 안전한 메서드와 비안전 메서드를 구분하여 사용자에게 비안전 동작을 요청하기 전에 이를 알릴 수 있어야 합니다(SHOULD).

대상 URI 내의 매개변수가 동작 선택의 효과를 가지도록 리소스를 구성한 경우, 그 동작이 요청 메서드 의미와 일치하도록 하는 것은 리소스 소유자의 책임입니다. 예를 들어 "page?do=delete"와 같은 쿼리 매개변수로 동작을 지정하는 웹 기반 편집 소프트웨어에서는 해당 리소스가 안전한 요청 메서드로 액세스될 때 그 동작을 비활성화하거나 허용하지 않아야 합니다. 그렇지 않으면 자동화된 프로세스가 모든 URI 참조에 대해 GET을 수행할 때 원치 않는 부작용이 발생할 수 있습니다.

요청 메서드는 동일한 요청을 여러 번 보냈을 때 서버에 대한 의도된 효과가 단일 요청과 동일하면 idempotent(멱등)로 간주됩니다. 이 명세서에서 정의된 메서드 중 PUT, DELETE 및 안전한 요청 메서드는 멱등입니다.

안전의 정의와 마찬가지로, 멱등성 속성은 사용자가 요청한 것에만 적용됩니다. 서버는 각 요청을 별도로 기록하거나 수정 이력 관리를 유지하거나 멱등 요청마다 비멱등적인 부작용을 구현할 수 있습니다.

멱등성 메서드는 통신 실패로 인해 클라이언트가 서버 응답을 읽기 전에 동일 요청을 반복해야 할 때 자동으로 재시도할 수 있기 때문에 구별됩니다. 예를 들어, 클라이언트가 PUT 요청을 보냈고 기초 연결이 응답을 받기 전에 닫혔다면, 클라이언트는 새 연결을 설정하고 멱등 요청을 재시도할 수 있습니다. 원래 요청이 성공했더라도 반복 요청은 동일한 의도된 효과를 갖게 됩니다(응답은 다를 수 있음).

클라이언트는 요청이 실제로 멱등적이라는 것을 알 수 있는 수단이 없으면 비멱등 메서드를 자동으로 재시도해서는 SHOULD NOT 합니다.

예를 들어, 사용자 에이전트는 그 요청이 해당 리소스에 대해 안전하다고 알려져 있는 경우 POST 요청을 자동으로 반복할 수 있습니다. 유사하게, 버전 관리 저장소에서 작동하도록 설계된 사용자 에이전트는 실패한 연결 후 대상 리소스의 수정(들)을 확인하고 부분 적용된 변경을 되돌리거나 수정한 뒤 실패한 요청을 자동으로 재시도할 수 있습니다.

일부 클라이언트는 자동 재시도가 가능한 시점을 추측하는 더 위험한 접근을 취합니다. 예를 들어, 클라이언트는 응답의 어떤 부분도 수신되지 않았을 경우 POST 요청을 자동으로 재시도할 수 있습니다(특히 유휴 지속 연결이 사용된 경우).

프록시는 비멱등 요청을 자동으로 재시도해서는 MUST NOT 합니다. 클라이언트는 실패한 자동 재시도를 자동으로 재시도해서는 SHOULD NOT 합니다.

캐시가 응답을 저장하고 사용하려면, 관련 메서드가 명시적으로 캐싱을 허용하고 어떤 조건에서 응답을 후속 요청을 만족시키는 데 사용할 수 있는지 자세히 규정해야 합니다. 메서드 정의가 이를 규정하지 않으면 캐시할 수 없습니다. 추가 요구사항은 [CACHING]를 참조하십시오.

이 명세서는 GET, HEAD 및 POST에 대한 캐싱 의미를 정의하지만, 대부분의 캐시 구현은 GET과 HEAD만 지원합니다.

GET 메서드는 선택된 표현(selected representation)의 전송을 요청합니다. 성공적인 응답은 대상 URI가 식별하는 동일성의 정도("sameness")를 반영합니다(자세한 내용은 Section 1.2.2 참조). 따라서 HTTP를 통한 식별 가능한 정보의 검색은 보통 해당 식별자에 대해 GET 요청을 수행하여 200 (OK) 응답으로 정보가 제공되는 방식으로 이루어집니다.

GET은 정보 검색의 주요 메커니즘이며 거의 모든 성능 최적화의 대상입니다. 중요한 리소스마다 URI를 생성하는 애플리케이션은 이러한 최적화를 활용하고 다른 애플리케이션이 재사용할 수 있어 웹의 확장을 촉진합니다.

리소스 식별자를 원격 파일 시스템 경로명으로, 표현을 이러한 파일의 내용 복사로 생각하기 쉽지만 실제 구현에는 제약이 없습니다(관련 보안 고려사항은 섹션 17.3 참조).

리소스의 HTTP 인터페이스는 콘텐츠 객체의 트리, 데이터베이스 레코드에 대한 프로그래밍적 뷰, 또는 다른 정보 시스템에 대한 게이트웨이로 구현될 수 있습니다. 심지어 URI 매핑이 파일 시스템에 연결된 경우에도 출처 서버는 요청을 입력으로 파일을 실행하고 출력을 표현으로 전송하도록 구성될 수 있습니다. 결국 어떤 리소스 식별자가 구현과 어떻게 대응하는지, 그리고 출처 서버가 대상 리소스의 현재 표현을 선택하고 전송하는 방법은 출처 서버만 알면 됩니다.

클라이언트는 Range 헤더 필드를 전송하여 GET의 의미를 "범위 요청"으로 변경할 수 있으며, 이는 선택된 표현의 일부(pieces)만 전송하도록 요청합니다(섹션 14.2).

요청 메시지 프레이밍은 사용된 메서드와 독립적이지만, GET 요청에서 수신된 콘텐츠는 일반적으로 정해진 의미가 없고 요청의 의미나 대상을 변경할 수 없습니다. 일부 구현은 요청 스머글링 공격의 가능성 때문에 이러한 요청을 거부하고 연결을 닫을 수 있습니다(섹션 11.2 참조). 클라이언트는 출처 서버가 사전에 그러한 요청을 지원한다고 표시하지 않는 한 GET 요청에 콘텐츠를 생성해서는 SHOULD NOT 합니다. 출처 서버는 사적 합의를 통해 콘텐츠 수신에 의존해서는 안 됩니다.

GET 요청에 대한 응답은 캐시 가능하며, 캐시는 Cache-Control 헤더 필드(섹션 5.2)에 달리 명시되지 않는 한 이후의 GET 및 HEAD 요청을 만족시키는 데 이를 사용할 수 있습니다.

사용자 제공 정보를 사용해 대상 URI를 구성하는 메커니즘(예: 폼의 쿼리 필드)을 통해 정보 검색을 수행할 때, 민감한 데이터가 URI에 포함되어 노출될 수 있습니다(관련 사항은 섹션 17.9 참조). 경우에 따라 이러한 데이터를 필터하거나 변환하여 노출을 방지할 수 있습니다. 캐시 사용의 이점이 거의 없는 경우에는 POST를 사용하여 데이터를 요청 콘텐츠로 전송하는 것이 더 적절할 수 있습니다(섹션 9.3.3).

HEAD 메서드는 GET과 동일하지만 서버는 응답에 콘텐츠를 전송해서는 MUST NOT 합니다. HEAD는 선택된 표현에 대한 메타데이터를 전송량 없이 얻는 데 사용되며, 하이퍼텍스트 링크 테스트나 최근 수정 여부 확인에 종종 사용됩니다.

서버는 HEAD 요청에 대해 GET 요청에 보냈을 동일한 헤더 필드를 보내는 것이 SHOULD 합니다. 다만, 콘텐츠를 생성하는 동안에만 값이 결정되는 헤더 필드는 생략할 수 있습니다. 예를 들어 일부 서버는 동적 GET 응답을 버퍼링하여 작은 응답을 보다 효율적으로 구분하거나 콘텐츠 선택에 대한 늦은 결정을 내리는데, 그러한 GET 응답에는 Content-Length 및 Vary 필드가 포함될 수 있지만 HEAD 응답에서는 생성되지 않을 수 있습니다. 이러한 소소한 불일치는 보통 HEAD 요청이 효율성을 위해 사용되므로 콘텐츠를 생성하고 폐기하는 것보다 바람직합니다.

요청 메시지 프레이밍은 메서드와 독립적이지만, HEAD 요청에서 수신된 콘텐츠는 일반적으로 의미가 없고 요청의 의미나 대상을 변경할 수 없으며 요청 스머글링 공격 가능성 때문에 일부 구현이 요청을 거부할 수 있습니다(섹션 11.2 참조). 클라이언트는 출처 서버가 사전에 그러한 요청을 지원한다고 표시하지 않는 한 HEAD 요청에 콘텐츠를 생성해서는 SHOULD NOT 합니다. 출처 서버는 사적 합의를 통해 콘텐츠 수신에 의존해서는 안 됩니다.

HEAD 요청에 대한 응답은 캐시 가능하며, 캐시는 Cache-Control 헤더 필드에 달리 명시되지 않는 한 이후의 HEAD 요청을 만족시키는 데 이를 사용할 수 있습니다. 또한 HEAD 응답은 이전에 캐시된 GET 응답에 영향을 줄 수 있습니다(자세한 내용은 Section 4.3.5 참조).

• HTML 폼에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공;
• 게시판, 뉴스그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시;
• 출처 서버에서 아직 식별되지 않은 새 리소스 생성;
• 리소스의 기존 표현에 데이터 추가.

출처 서버는 POST 요청 처리 결과에 따라 적절한 상태 코드를 선택하여 응답 의미를 나타냅니다. 이 명세서에서 정의된 거의 모든 상태 코드는 POST 응답으로 수신될 수 있습니다(예외: 206, 304, 416).

하나 이상의 리소스가 POST 처리의 결과로 출처 서버에 생성된 경우, 출처 서버는 주 생성 리소스의 식별자를 제공하는 201 (Created) 응답과 함께 Location 헤더 필드를 포함하고 요청 상태를 설명하는 표현을 제공하는 것이 SHOULD 합니다.

POST 요청에 대한 응답은 명시적 신선도 정보가 포함된 경우에만 캐시할 수 있습니다(자세한 내용은 Section 4.2.1 참조). 또한 응답에 포함된 Content-Location 헤더 필드가 POST의 대상 URI와 동일한 값을 가지면 캐시된 POST 응답은 이후의 GET 또는 HEAD 요청을 만족시키는 데 재사용될 수 있습니다. 반대로 POST 요청은 잠재적으로 안전하지 않으므로 캐시된 POST 응답으로 만족될 수 없습니다.

POST 처리 결과가 기존 리소스의 표현과 동등하다면 출처 서버는 사용자 에이전트를 해당 리소스로 리디렉션하기 위해 303 (See Other) 응답을 보낼 수 있습니다. 이는 사용자 에이전트에 리소스 식별자를 제공하고 표현을 공유 캐시에 더 적합한 메서드로 전송하게 하여 이점이 있지만, 사용자 에이전트가 해당 표현을 캐시하지 않은 경우 추가 요청 비용이 발생할 수 있습니다.

PUT 메서드는 요청 메시지 콘텐츠에 포함된 표현으로 대상 리소스의 상태를 생성하거나 대체하도록 요청합니다. 주어진 표현의 성공적인 PUT은 이후 동일한 대상 리소스에 대한 GET이 동등한 표현을 반환할 것임을 시사합니다. 다만 대상 리소스가 병렬로 다른 에이전트에 의해 조작되거나 출처 서버의 동적 처리 대상일 수 있으므로 그러한 상태 변경이 관찰 가능할 것이라는 보장은 없습니다. 성공 응답은 단지 출처 서버가 처리한 시점에서 사용자 에이전트의 의도가 달성되었음을 의미합니다.

대상 리소스에 현재 표현이 없고 PUT으로 성공적으로 생성된 경우 출처 서버는 201 (Created) 응답을 전송해야 MUST 합니다. 대상 리소스에 현재 표현이 있고 해당 표현이 요청에 포함된 표현 상태에 따라 성공적으로 수정된 경우 출처 서버는 성공을 나타내기 위해 200 (OK) 또는 204 (No Content) 응답을 전송해야 MUST 합니다.

출처 서버는 PUT 표현이 대상 리소스의 구성 제약과 일치하는지 검증해야 SHOULD 합니다. 예를 들어 출처 서버가 리소스의 표현 메타데이터를 URI에 따라 결정한다면, 성공적인 PUT 요청에서 받은 콘텐츠가 해당 메타데이터와 일치하는지 확인해야 합니다. PUT 표현이 대상 리소스와 일치하지 않으면 출처 서버는 표현을 변환하거나 리소스 구성을 변경하여 일치시키거나, 해당 표현이 부적합함을 설명하는 적절한 오류 메시지로 요청을 거부해야 SHOULD 합니다. 제안된 상태 코드로는 409 (Conflict) 또는 415 (Unsupported Media Type) 등이 있습니다.

1. 대상 리소스의 미디어 타입을 새 미디어 타입에 맞게 재구성;
2. 저장하기 전에 PUT 표현을 리소스와 일치하는 형식으로 변환;
3. 요청을 거부하고 대상 리소스가 "text/html"로 제한되어 있음을 나타내는 415 (Unsupported Media Type) 응답을 전송(필요하면 새 표현에 적합한 다른 리소스에 대한 링크 포함).

HTTP는 PUT 메서드가 출처 서버의 상태에 어떻게 영향을 미치는지를 정확히 정의하지 않습니다. 리소스가 무엇인지, 상태가 어떻게 저장되는지, 저장 방식이 상태 변경으로 인해 어떻게 변하는지, 출처 서버가 리소스 상태를 표현으로 어떻게 변환하는지는 정의하지 않습니다. 일반적으로 리소스 인터페이스 뒤의 모든 구현 세부사항은 서버에 의해 숨겨집니다.

이는 헤더 및 트레일러 필드의 저장 방식에도 확장됩니다. 일반적인 헤더 필드(예: Content-Type)는 보통 저장되어 이후의 GET 요청에 반환되지만, 헤더 및 트레일러 필드 처리 방법은 해당 요청을 수신한 리소스에 특정합니다. 결과적으로 출처 서버는 PUT 요청에서 수신된 인식되지 않은 헤더 및 트레일러 필드를 리소스 상태의 일부로 저장해서는 안 되며 이를 무시하는 것이 SHOULD 합니다.

출처 서버는 요청의 표현 데이터가 변환 없이 저장되지 않고 그 값이 새 표현과 동일할 때에만 성공 응답에 밸리데이터 필드(예: ETag 또는 Last-Modified)를 전송해서는 MUST NOT 합니다. 이는 사용자 에이전트가 자신이 보유한 표현이 PUT의 결과임을 알고 다시 가져올 필요가 없도록 하기 위함입니다. 응답에서 받은 새 밸리데이터는 이후의 조건부 요청에 사용될 수 있습니다.

POST와 PUT의 근본적 차이는 포함된 표현의 의도에서 드러납니다. POST의 대상 리소스는 포함된 표현을 리소스 고유의 의미에 따라 처리하도록 의도되는 반면, PUT의 포함 표현은 대상 리소스의 상태를 대체하도록 정의됩니다. 따라서 PUT은 멱등적이며 중개자에게 가시적입니다.

PUT 요청을 올바르게 해석하려면 사용자 에이전트가 원하는 대상 리소스를 알아야 합니다. 클라이언트를 대신해 적절한 URI를 선택하는 서비스는 PUT 대신 POST로 구현되어야 SHOULD 합니다. 출처 서버가 요청된 PUT 상태 변경을 대상 리소스에 적용하지 않고 다른 리소스에 적용하려는 경우(예: 리소스가 다른 URI로 이동된 경우) 출처 서버는 적절한 3xx 리디렉션 응답을 보내야 MUST 하며, 사용자 에이전트는 리디렉션할지 여부를 선택할 수 있습니다.

대상 리소스에 적용된 PUT 요청은 다른 리소스에 부작용을 초래할 수 있습니다. 예를 들어 "현재 버전"을 식별하는 URI가 각 특정 버전의 URI와 분리되어 있는 경우, "현재 버전" URI에 대한 성공적인 PUT은 새 버전 리소스를 생성하고 관련 리소스 간에 링크를 추가할 수 있습니다.

일부 출처 서버는 요청 수정자로서 Content-Range 헤더 필드의 사용을 지원하여 부분 PUT(Partial PUT)을 수행할 수 있습니다(자세한 내용은 섹션 14.5 참조).

PUT 메서드에 대한 응답은 캐시할 수 없습니다. 성공적인 PUT 요청이 대상 URI에 대해 하나 이상의 저장된 응답을 가진 캐시를 통과하면, 그 저장된 응답들은 무효화됩니다(자세한 내용은 Section 4.4 참조).

DELETE 메서드는 출처 서버가 대상 리소스과 그 현재 기능 간의 연관을 제거하도록 요청합니다. 효과적으로 이 메서드는 UNIX의 "rm" 명령과 유사하며, 출처 서버의 URI 매핑에 대한 삭제 연산을 표현하지 이전 정보 자체가 삭제되어야 함을 기대하지는 않습니다.

대상 리소스에 하나 이상의 현재 표현이 있는 경우, 그것들이 출처 서버에 의해 파괴되거나 관련 저장소가 회수될지는 리소스의 성격과 출처 서버의 구현에 따라 다릅니다. 또한 DELETE로 인해 데이터베이스나 게이트웨이 연결 같은 다른 구현 측면이 비활성화되거나 보관되어야 할 수 있습니다. 일반적으로 출처 서버는 DELETE를 수행할 기제가 있는 리소스에 대해서만 DELETE를 허용합니다.

비교적 적은 수의 리소스만 DELETE 메서드를 허용합니다. 주요 사용 사례는 원격 저작 환경으로, 사용자가 그 효과에 대해 어느 정도 지침을 가진 경우입니다. 예를 들어 PUT으로 생성되었거나 POST 응답의 Location 필드로 식별된 리소스는 해당 DELETE 요청을 허용할 수 있습니다. 또한 버전 관리 클라이언트처럼 HTTP를 원격 작업에 사용하는 맞춤형 사용자 에이전트는 서버의 URI 공간이 버전 저장소에 대응한다고 가정하고 DELETE를 사용할 수 있습니다.

DELETE가 성공적으로 적용되면 출처 서버는 다음 중 하나를 보내는 것이 SHOULD 합니다:

• 작업이 아직 실행되지 않았지만 성공할 가능성이 있는 경우 202 (Accepted) 상태 코드,
• 작업이 실행되었고 추가 정보가 제공되지 않는 경우 204 (No Content) 상태 코드,
• 작업이 실행되었고 상태를 설명하는 표현을 응답 메시지에 포함하는 경우 200 (OK) 상태 코드.

요청 메시지 프레이밍은 메서드와 독립적이지만 DELETE 요청에서 수신된 콘텐츠는 일반적으로 의미가 없고 요청의 의미나 대상을 변경할 수 없으며 요청 스머글링 공격의 잠재성 때문에 일부 구현은 이를 거부하고 연결을 닫을 수 있습니다. 클라이언트는 출처 서버가 사전에 그러한 요청을 지원한다고 표시하지 않는 한 DELETE 요청에 콘텐츠를 생성해서는 SHOULD NOT 합니다. 출처 서버는 사적 합의를 통해 콘텐츠 수신에 의존해서는 안 됩니다.

DELETE 메서드에 대한 응답은 캐시할 수 없습니다. 성공적인 DELETE 요청이 대상 URI에 대해 하나 이상의 저장된 응답을 가진 캐시를 통과하면, 그 저장된 응답들은 무효화됩니다(자세한 내용은 Section 4.4 참조).

CONNECT 메서드는 수신자에게 요청 대상이 식별하는 목적지 출처 서버로의 터널을 설정하도록 요청합니다. 성공하면 이후 터널이 닫힐 때까지 양방향으로 블라인드 포워딩만 수행해야 합니다. 터널은 하나 이상의 프록시를 통해 종단 간 가상 연결을 생성하는 데 일반적으로 사용되며, 이후 TLS로 보호될 수 있습니다.

CONNECT는 이 메서드 고유의 요청 대상 형식을 사용하며, 터널 목적지의 호스트 이름과 포트 번호만으로 구성됩니다(콜론으로 구분). 기본 포트는 없으므로 클라이언트는 CONNECT 요청에 포트 번호를 반드시 전송해야 MUST 합니다. 예:

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

서버는 빈 포트나 잘못된 포트를 대상으로 하는 CONNECT 요청을 거부해야 MUST 하며, 일반적으로 400 (Bad Request)로 응답합니다.

CONNECT는 HTTP 연결의 요청/응답 성격을 변경하므로 특정 HTTP 버전은 그 의미를 프로토콜의 와이어 포맷으로 매핑하는 방법이 다를 수 있습니다.

CONNECT는 프록시에 대한 요청에서 사용하도록 의도되었습니다. 수신자는 요청 대상이 식별하는 서버에 직접 연결하거나 다른 프록시를 사용하도록 구성된 경우 다음 인바운드 프록시로 CONNECT 요청을 전달하여 터널을 설정할 수 있습니다. 출처 서버는 CONNECT를 허용할 수는 있지만 대부분은 구현하지 않습니다.

어떤 2xx (Successful) 응답도 송신자(및 모든 인바운드 프록시)가 응답 헤더 섹션 직후 터널 모드로 전환할 것임을 나타냅니다. 그 이후에 수신되는 데이터는 요청 대상이 식별하는 서버에서 온 데이터입니다. 성공 응답이 아닌 모든 응답은 터널이 아직 형성되지 않았음을 나타냅니다.

터널은 터널 중개자가 양쪽 중 하나가 연결을 닫았음을 감지하면 종료됩니다. 중개자는 닫힌 쪽에서 온 미전송 데이터를 상대쪽으로 전송하려 시도하고, 두 연결을 닫은 뒤 남아 있는 데이터를 폐기해야 MUST 합니다.

프록시 인증은 터널 생성 권한을 확립하는 데 사용될 수 있습니다. 예:

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=

임의의 서버로 터널을 설정하는 데에는 큰 위험이 있습니다. 특히 목적지가 웹 트래픽용이 아닌 잘 알려진 또는 예약된 TCP 포트일 때 위험이 큽니다. 예를 들어 "example.com:25"로의 CONNECT는 프록시가 SMTP 포트로 연결하게 하여 스팸 중계를 유발할 수 있습니다. CONNECT를 지원하는 프록시는 사용을 제한된 포트 집합이나 구성 가능한 안전한 대상 목록으로 제한해야 SHOULD 합니다.

서버는 CONNECT의 성공 응답에서 어떤 Transfer-Encoding 또는 Content-Length 헤더 필드를 보내서는 MUST NOT 합니다. 클라이언트는 성공 응답에서 수신된 Content-Length 또는 Transfer-Encoding 헤더 필드를 무시해야 MUST 합니다.

CONNECT 요청 메시지에는 콘텐츠가 없습니다. CONNECT 요청 메시지의 헤더 섹션 이후에 전송되는 데이터의 해석은 사용 중인 HTTP 버전에 따라 다릅니다.

CONNECT 메서드에 대한 응답은 캐시할 수 없습니다.

OPTIONS 메서드는 대상 리소스에 대해 사용 가능한 통신 옵션에 관한 정보를 요청합니다. 이 메서드는 클라이언트가 리소스와 통신할 때의 옵션 및/또는 요구사항이나 서버의 기능을 리소스 동작 없이 결정할 수 있게 합니다.

요청 대상이 별표("*")인 OPTIONS 요청은 특정 리소스가 아닌 서버 전체에 적용됩니다. 서버의 통신 옵션은 보통 리소스에 따라 달라지므로 "*" 요청은 "ping" 또는 "noop" 유형의 메서드로만 유용합니다. 예를 들어 이는 프록시가 HTTP/1.1을 준수하는지 테스트하는 데 사용될 수 있습니다.

요청 대상이 별표가 아니면 OPTIONS 요청은 대상 리소스와 통신할 때 사용 가능한 옵션에 적용됩니다.

서버는 OPTIONS에 대해 성공 응답을 생성할 때 대상 리소스에 적용될 수 있는 구현된 선택적 기능을 나타내는 헤더(예: Allow)를 보내는 것이 SHOULD 합니다. 응답 콘텐츠가 있다면 기계나 사람이 읽을 수 있는 표현으로 통신 옵션을 설명할 수 있습니다. 표준 형식은 이 명세서에서 정의되지 않습니다.

클라이언트는 요청 체인의 특정 수신자를 대상으로 하기 위해 OPTIONS 요청에 Max-Forwards 헤더 필드를 보낼 수 있습니다. 프록시는 수신된 요청에 Max-Forwards 필드가 없는 한 전달하면서 Max-Forwards 헤더를 생성해서는 MUST NOT 합니다.

콘텐츠를 포함하는 OPTIONS 요청을 생성하는 클라이언트는 표현 미디어 타입을 설명하는 유효한 Content-Type 헤더 필드를 보내야 MUST 합니다. 이 명세서는 그러한 콘텐츠의 사용을 정의하지 않습니다.

OPTIONS 메서드에 대한 응답은 캐시할 수 없습니다.

TRACE 메서드는 요청 메시지의 원격 애플리케이션 수준 루프백을 요청합니다. 요청의 최종 수신자는 수신한 메시지를 (아래에 설명된 일부 필드를 제외하고) 응답 본문의 콘텐츠로 클라이언트에게 반사하여 돌려줘야 SHOULD 합니다. "message/http" 포맷은 이를 수행하는 한 방법입니다. 최종 수신자는 출처 서버이거나 요청에서 Max-Forwards 값이 0인 첫 번째 서버입니다.

클라이언트는 TRACE 요청에 응답으로 노출될 수 있는 민감한 데이터를 포함하는 필드를 생성해서는 MUST NOT 합니다. 예를 들어 사용자 자격증명이나 쿠키를 TRACE 요청에 포함하는 것은 바람직하지 않습니다. 최종 수신자는 응답 콘텐츠를 생성할 때 민감한 데이터를 포함할 가능성이 있는 요청 필드를 제외해야 SHOULD 합니다.

TRACE는 클라이언트가 요청 체인에서 다른 쪽 끝에서 무엇이 수신되는지를 확인하고 테스트나 진단 정보를 얻는 데 사용됩니다. 특히 Via 헤더 필드 값은 요청 체인의 추적으로서 유용합니다. Max-Forwards 헤더 필드의 사용은 요청 체인의 길이를 제한할 수 있어 무한 루프를 포워딩하는 프록시 체인을 테스트할 때 유용합니다.

클라이언트는 TRACE 요청에 콘텐츠를 전송해서는 MUST NOT 합니다.

TRACE 메서드에 대한 응답은 캐시할 수 없습니다.

요청의 "Expect" 헤더 필드는 이 요청을 적절히 처리하기 위해 서버가 지원해야 하는 특정 동작 집합(기대치)을 나타냅니다.

  Expect =      #expectation
  expectation = token [ "=" ( token / quoted-string ) parameters ]

Expect 필드 값은 대소문자 구분이 없습니다.

이 명세에서 정의된 유일한 기대치는 인자 없는 "100-continue"입니다.

100-continue 이외의 멤버를 포함하는 Expect 필드 값을 수신한 서버는 그 예상치 못한 기대치를 충족할 수 없음을 나타내기 위해 417 (Expectation Failed) 상태 코드로 응답할 수 MAY 있습니다.

100-continue 기대치는 클라이언트가 이 요청에서 (아마도 큰) 콘텐츠를 전송하려고 하며, 메서드, 대상 URI 및 헤더 필드만으로 즉시 성공, 리디렉션 또는 오류 응답이 결정되지 않는다면 100 (Continue) 중간 응답을 받고자 함을 수신자에게 알립니다. 이는 클라이언트가 실제로 콘텐츠를 전송하기 전에 전송을 시작할 가치가 있는지를 확인할 수 있게 하여, 데이터가 거대하거나 오류가 발생할 가능성이 높다고 예상되는 경우(예: 상태 변경 메서드를 처음으로 인증 자격 증명 없이 보낼 때) 효율성을 개선할 수 있습니다.

예를 들어, 다음과 같이 시작하는 요청은

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

클라이언트가 불필요한 대용량 데이터 전송을 시작하기 전에 출처 서버가 즉시 401 (Unauthorized) 또는 405 (Method Not Allowed) 같은 오류 메시지로 응답할 수 있도록 합니다.

• 클라이언트는 콘텐츠를 포함하지 않는 요청에서 100-continue 기대치를 생성해서는 MUST NOT 합니다.
• 100 (Continue) 응답을 기다렸다가 요청 콘텐츠를 전송하려는 클라이언트는 Expect 헤더 필드에 100-continue 기대치를 포함하여 전송해야 MUST 합니다.
• 100-continue 기대치를 전송하는 클라이언트는 특정 시간 동안 기다릴 의무가 없습니다; 그러한 클라이언트는 응답을 아직 받지 못했더라도 콘텐츠를 전송할 수 MAY 합니다. 또한 100 (Continue) 응답은 HTTP/1.0 중개자를 통해 전송될 수 없으므로, 이러한 클라이언트는 콘텐츠를 전송하기 전에 무기한 대기해서는 SHOULD NOT 합니다.
• 100-continue 기대치를 포함한 요청에 대해 417 (Expectation Failed) 상태 코드를 수신한 클라이언트는, 417 응답이 단지 응답 체인이 기대치를 지원하지 않음을 나타내므로(예: HTTP/1.0 서버를 통과함) 100-continue 기대치 없이 동일한 요청을 반복해야 SHOULD 합니다.

• HTTP/1.0 요청에서 100-continue 기대치를 수신한 서버는 그 기대치를 무시해야 MUST 합니다.
• 서버는 해당 요청에 대한 일부 또는 전부의 콘텐츠를 이미 수신했거나 프레이밍이 콘텐츠가 없음을 나타내는 경우 100 (Continue) 응답을 생략할 수 MAY 있습니다.
• 100 (Continue) 응답을 전송한 서버는 요청 콘텐츠를 수신하고 처리한 후 최종 상태 코드를 반드시 전송해야 MUST 합니다(연결이 조기에 종료되지 않는 한).
• 최종 상태 코드로 응답하기 전에 전체 요청 콘텐츠를 읽지 않은 서버는 연결을 닫을 의사가 있는지(예: 섹션 9.6 참조) 또는 계속 읽을 것인지 여부를 표시해야 SHOULD 합니다.

• 메서드, 대상 URI 및 헤더 필드만 검사하여 결정할 수 있는 최종 상태 코드로 즉시 응답, 또는
• 클라이언트가 요청 콘텐츠를 전송하도록 권장하기 위한 즉시 100 (Continue) 응답.

출처 서버는 100 (Continue) 응답을 보내기 전에 콘텐츠를 기다려서는 MUST NOT 합니다.

• 메서드, 대상 URI 및 헤더 필드만 검사하여 결정할 수 있는 최종 상태 코드로 즉시 응답을 전송하거나,
• 해당 요청과 일치하는 요청 라인과 헤더 섹션을 다음 인바운드 서버로 보내 출처 서버 쪽으로 요청을 전달한다.

프록시가 구성 또는 과거 상호작용으로부터 다음 인바운드 서버가 HTTP/1.0만 지원한다고 생각하면, 프록시는 클라이언트가 콘텐츠 전송을 시작하도록 장려하기 위해 즉시 100 (Continue) 응답을 생성할 수 MAY 있습니다.

  From    = mailbox

  mailbox = <mailbox, see [RFC5322], Section 3.4>

From: spider-admin@example.org

From 헤더 필드는 비로봇 사용자 에이전트에서는 거의 전송되지 않습니다. 사용자 에이전트는 사용자의 명시적 구성 없이는 From 헤더 필드를 전송해서는 SHOULD NOT 합니다. 이는 사용자의 프라이버시 이익이나 사이트의 보안 정책과 충돌할 수 있기 때문입니다.

로봇 사용자 에이전트는 문제가 발생했을 때 로봇을 운영하는 담당자에게 연락할 수 있도록 유효한 From 헤더 필드를 전송해야 SHOULD 합니다(예: 로봇이 과다하거나 원치 않는, 또는 잘못된 요청을 보내는 경우).

서버는 From 헤더 필드를 접근 제어나 인증에 사용해서는 SHOULD NOT 합니다. From 값은 요청을 수신하거나 관찰하는 누구에게나 보이는 것이 예상되며 로그 파일과 오류 보고서에 기록될 수 있어 프라이버시 기대와 일치하지 않기 때문입니다.

"Referer" [sic] 헤더 필드는 사용자 에이전트가 대상 URI를 얻은 리소스의 URI 참조(즉, "referrer", 필드 이름은 철자 오류가 있음)를 지정할 수 있게 합니다. 사용자 에이전트는 URI 참조를 생성할 때 fragment 및 userinfo 구성요소가 있으면 이를 포함해서는 MUST NOT 합니다([URI] 참조).

  Referer = absolute-URI / partial-URI

필드 값은 absolute-URI 또는 partial-URI입니다. 후자의 경우(섹션 4 참조), 참조된 URI는 대상 URI에 상대적입니다.

Referer 헤더 필드는 서버가 간단한 분석, 로깅, 최적화된 캐싱 등을 위해 다른 리소스에 대한 백링크를 생성할 수 있게 합니다. 또한 유지보수를 위해 오래되거나 잘못된 링크를 찾는 데 도움을 줍니다. 일부 서버는 Referer 헤더 필드를 다른 사이트로부터의 링크(이른바 "deep linking")를 차단하거나 CSRF(교차 사이트 요청 위조)를 제한하는 수단으로 사용하지만, 모든 요청이 이를 포함하는 것은 아닙니다.

Referer: http://www.example.org/hypertext/Overview.html

대상 URI가 자체 URI가 없는 출처(예: 사용자 키보드 입력 또는 사용자의 북마크/즐겨찾기 항목)에서 얻어진 경우, 사용자 에이전트는 Referer 헤더 필드를 제외하거나 값으로 "about:blank"를 보내야 MUST 합니다.

Referer 헤더 필드 값은 반드시 참조하는 리소스의 전체 URI를 전달할 필요는 없습니다; 사용자 에이전트는 참조 출처(origin) 이외의 부분을 잘라낼 수 MAY 있습니다.

Referer 헤더는 참조 리소스의 식별자가 개인 정보를 드러내거나(예: 계정 이름) 방화벽 뒤 또는 보안 서비스 내부처럼 기밀로 간주되는 리소스를 드러내는 경우 요청 컨텍스트나 사용자의 방문 기록에 관한 정보를 유출할 가능성이 있어 프라이버시 문제를 일으킬 수 있습니다. 대부분의 범용 사용자 에이전트는 참조 리소스가 로컬 "file" 또는 "data" URI인 경우 Referer 헤더를 전송하지 않습니다. 사용자 에이전트는 참조 리소스가 보안 프로토콜로 액세스되었고 요청 대상이 참조 리소스의 origin과 다르면 Referer를 전송해서는 SHOULD NOT 하며, 참조 리소스가 명시적으로 Referer 전송을 허용하지 않는 한 전송해서는 MUST NOT 합니다. 추가 보안 고려사항은 섹션 17.9를 참조하십시오.

일부 중개자는 아웃고잉 요청에서 Referer 헤더 필드를 무차별적으로 제거하는 것으로 알려져 있습니다. 이는 CSRF 공격에 대한 보호를 방해하여 사용자에게 훨씬 더 해로울 수 있습니다. 정보 공개를 제한하려는 중개자와 사용자 에이전트 확장자는 내부 도메인 이름을 의사명으로 교체하거나 쿼리 및/또는 경로 구성요소를 잘라내는 등의 특정 편집으로 변경을 제한해야 합니다. 중개자는 필드 값이 대상 URI와 동일한 스킴 및 호스트를 공유하는 경우 Referer 헤더 필드를 변경하거나 삭제해서는 SHOULD NOT 합니다.

"TE" 헤더 필드는 전송 코딩 및 트레일러 섹션에 관해 클라이언트의 능력을 설명합니다.

섹션 6.5에서 설명한 바와 같이, 요청에서 "trailers" 멤버가 있는 TE 필드는 클라이언트가 트레일러 필드를 버리지 않을 것임을 나타냅니다.

TE는 또한 HTTP/1.1에서 서버에게 응답에서 클라이언트가 수용할 수 있는 전송 코딩을 알리는 데 사용됩니다. 발행 시점 기준으로 전송 코딩을 사용하는 것은 HTTP/1.1뿐입니다(자세한 내용은 Section 7 참조).

TE 필드 값은 멤버들의 목록이며, "trailers"를 제외한 각 멤버는 선택적 가중치로 클라이언트가 해당 전송 코딩에 대한 상대적 선호도를 표시하는 전송 코딩 이름 토큰과 해당 전송 코딩에 대한 선택적 파라미터로 구성됩니다(섹션 12.4.2 참조).

  TE                 = #t-codings
  t-codings          = "trailers" / ( transfer-coding [ weight ] )
  transfer-coding    = token *( OWS ";" OWS transfer-parameter )
  transfer-parameter = token BWS "=" BWS ( token / quoted-string )

TE를 전송하는 발신자는 또한 중개자가 이 필드를 전달하지 않도록 알리기 위해 Connection 헤더 필드에 "TE" connection option을 포함시켜야 MUST 합니다(섹션 7.6.1 참조).

"User-Agent" 헤더 필드는 요청을 생성한 사용자 에이전트에 관한 정보를 포함하며, 서버가 상호운용성 문제 범위를 식별하거나 특정 사용자 에이전트의 제한을 우회하거나 응답을 조정하는 데 자주 사용됩니다. 사용자 에이전트는 특별히 구성되지 않는 한 각 요청에 User-Agent 헤더 필드를 보내는 것이 SHOULD 합니다.

  User-Agent = product *( RWS ( product / comment ) )

User-Agent 필드 값은 하나 이상의 제품 식별자로 구성되며, 각 식별자 뒤에는 0개 이상의 주석(섹션 5.6.5)이 올 수 있습니다. 이들은 함께 사용자 에이전트 소프트웨어와 그 중요한 하위 제품을 식별합니다. 관례적으로 제품 식별자는 중요도 순서로 나열됩니다. 각 제품 식별자는 이름과 선택적 버전으로 이루어집니다.

  product         = token ["/" product-version]
  product-version = token

발신자는 생성된 제품 식별자를 제품을 식별하는 데 필요한 범위로 제한해야 SHOULD 하며, 광고나 기타 비본질적인 정보를 제품 식별자 내에 생성해서는 MUST NOT 합니다. 또한 product-version에 버전 식별자가 아닌 정보를 생성해서는 SHOULD NOT 합니다(동일 제품 이름의 연속 버전은 product-version 부분만 달라야 함).

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

사용자 에이전트는 불필요하게 세세한 정보를 포함한 User-Agent 헤더 필드를 생성해서는 SHOULD NOT 하며, 제3자에 의한 하위 제품 추가를 제한해야 SHOULD 합니다. 지나치게 길고 상세한 User-Agent 값은 요청 지연을 증가시키고 사용자 식별 위험("fingerprinting")을 높입니다.

유사하게, 구현체는 호환성을 선언하기 위해 다른 구현체의 product 토큰을 사용하는 것을 권장하지 않습니다. 사용자 에이전트가 다른 사용자 에이전트로 가장하면, 수신자는 해당 식별된 사용자 에이전트에 맞춘 응답을 보려는 의도로 간주할 수 있으며, 실제로는 그 응답이 잘 동작하지 않을 수 있습니다.

"Allow" 헤더 필드는 대상 리소스가 지원한다고 광고하는 메서드 집합을 나열합니다. 이 필드의 목적은 리소스와 연관된 유효한 요청 메서드를 수신자에게 정보를 제공하는 데에만 있습니다.

  Allow = #method

Allow: GET, HEAD, PUT

허용된 실제 메서드 집합은 각 요청 시점에 출처 서버에 의해 정의됩니다. 출처 서버는 405 (Method Not Allowed) 응답에서 Allow 헤더 필드를 반드시 생성해야 MUST 하며, 다른 응답에서는 생성할 수 MAY 있습니다. 빈 Allow 필드 값은 리소스가 어떤 메서드도 허용하지 않음을 나타내며, 이는 리소스가 구성상 일시적으로 비활성화된 경우 405 응답에서 발생할 수 있습니다.

프록시는 Allow 헤더 필드를 수정해서는 MUST NOT 합니다 — 프록시는 표시된 모든 메서드를 이해할 필요 없이 일반적인 메시지 처리 규칙에 따라 이를 처리할 수 있습니다.

"Location" 헤더 필드는 일부 응답에서 응답과 관련된 특정 리소스를 참조하는 데 사용됩니다. 관계의 유형은 요청 메서드와 상태 코드 의미의 조합에 의해 정의됩니다.

  Location = URI-reference

필드 값은 단일 URI-reference로 구성됩니다. 상대 참조 형태일 때([URI] 참조), 최종 값은 대상 URI에 대해 해석하여 계산됩니다.

201 (Created) 응답의 경우 Location 값은 요청으로 생성된 주된 리소스를 가리킵니다. 3xx (Redirection) 응답의 경우 Location 값은 자동으로 요청을 리디렉션할 때 선호되는 대상 리소스를 가리킵니다.

3xx 응답에 제공된 Location 값이 fragment 구성요소를 가지지 않는다면, 사용자 에이전트는 원래 대상 URI를 생성한 참조의 fragment를 상속하는 것처럼 리디렉션을 처리해야 MUST 합니다(즉, 리디렉션은 원래 참조의 fragment를 상속합니다).

Location: /People.html#tim

이는 사용자 에이전트가 "http://www.example.org/People.html#tim"으로 리디렉션하라는 제안을 합니다.

Location: http://www.example.net/index.html

이는 원래 fragment 식별자 "#larry"를 보존하여 "http://www.example.net/index.html#larry"로 리디렉션하라는 제안을 합니다.

Location 값에 fragment 식별자가 적절하지 않은 상황도 있습니다. 예를 들어, 201 (Created) 응답의 Location 헤더는 생성된 리소스에 특정한 URI를 제공해야 합니다.

서버는 "Retry-After" 헤더 필드를 보내어 사용자 에이전트가 후속 요청을 수행하기 전에 얼마나 기다려야 하는지를 나타냅니다. 503 (Service Unavailable) 응답과 함께 전송되는 경우, Retry-After는 서비스가 클라이언트에게 얼마나 오랫동안 이용 불가능할 것으로 예상되는지 나타냅니다. 모든 3xx (Redirection) 응답과 함께 전송되는 경우에는 리디렉션된 요청을 수행하기 전에 사용자 에이전트가 기다리도록 요청된 최소 시간을 나타냅니다.

Retry-After 필드 값은 HTTP-date 또는 응답 수신 후 지연할 초 수 중 하나일 수 있습니다.

  Retry-After = HTTP-date / delay-seconds

delay-seconds 값은 음이 아닌 10진 정수로, 초 단위를 나타냅니다.

  delay-seconds  = 1*DIGIT

사용 예 두 가지는 다음과 같습니다

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

후자의 예에서는 지연 시간이 2분입니다.

"Server" 헤더 필드는 요청을 처리하는 데 사용된 출처 서버 소프트웨어에 관한 정보를 포함하며, 이는 클라이언트가 보고된 상호운용성 문제의 범위를 식별하거나 특정 서버 제한을 우회하거나 응답을 조정하는 데 자주 사용됩니다. 출처 서버는 응답에 Server 헤더 필드를 생성할 수 MAY 있습니다.

  Server = product *( RWS ( product / comment ) )

Server 헤더 필드 값은 하나 이상의 제품 식별자로 구성되며, 각 식별자 뒤에는 0개 이상의 주석(섹션 5.6.5)이 올 수 있습니다. 이는 출처 서버 소프트웨어와 그 중요한 하위 제품을 식별합니다. 관례적으로 제품 식별자는 중요도 순서로 나열됩니다. 각 제품 식별자는 이름과 선택적 버전으로 이루어집니다(섹션 10.1.5 참조).

Server: CERN/3.0 libwww/2.17

출처 서버는 불필요하게 세세한 정보를 포함한 Server 헤더 필드를 생성해서는 SHOULD NOT 하며, 제3자에 의한 하위 제품 추가를 제한해야 SHOULD 합니다. 지나치게 길고 상세한 Server 값은 응답 지연을 증가시키고 내부 구현 세부사항을 노출하여 공격자가 알려진 보안 취약점을 찾고 악용하기 더 쉽게 만들 수 있습니다.

"WWW-Authenticate" 응답 헤더 필드는 대상 리소스에 적용되는 인증 스킴과 매개변수를 나타냅니다.

  WWW-Authenticate = #challenge

서버가 401 (Unauthorized) 응답을 생성하는 경우, 반드시 적어도 하나의 챌린지를 포함하는 WWW-Authenticate 헤더 필드를 전송해야 MUST 합니다. 서버는 응답에 자격 증명(또는 다른 자격 증명)을 제공하면 응답에 영향을 줄 수 있음을 나타내기 위해 다른 응답 메시지에서도 WWW-Authenticate 헤더 필드를 생성할 수 있습니다(MAY).

프록시가 응답을 전달할 때 해당 응답의 어떤 WWW-Authenticate 헤더 필드도 수정해서는 MUST NOT 합니다.

사용자 에이전트는 필드 값이 둘 이상의 챌린지를 포함할 수 있고 각 챌린지가 콤마로 구분된 인증 매개변수 목록을 포함할 수 있으므로 필드 값을 구문 분석할 때 특별히 주의해야 합니다. 또한 헤더 필드 자체가 여러 번 나타날 수 있습니다.

WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
                 type=1, title="Login to \"apps\""

이 헤더 필드는 "simple"이라는 realm 값을 가진 "Basic" 스킴에 대한 챌린지와 "apps"라는 realm 값을 가진 "Newauth" 스킴에 대한 다른 챌린지, 그리고 "type"과 "title"이라는 추가 매개변수 두 개를 포함합니다.

그러나 일부 사용자 에이전트는 이러한 형식을 인식하지 못할 수 있습니다. 결과적으로 같은 헤더 라인에 멤버가 둘 이상 포함된 WWW-Authenticate 필드 값을 보내는 것은 상호운용성이 없을 수 있습니다.

"Authorization" 헤더 필드는 사용자 에이전트가 출처 서버에 대해 자신을 인증할 수 있게 합니다 — 보통은 401 (Unauthorized) 응답을 받은 후입니다. 그 값은 요청된 리소스의 realm에 대한 사용자 에이전트의 인증 정보를 담은 자격 증명으로 구성됩니다.

  Authorization = credentials

요청이 인증되었고 realm이 지정된 경우, 동일한 자격 증명은 해당 realm 내의 다른 모든 요청에 대해 유효한 것으로 추정됩니다(인증 스킴 자체가 달리 요구하지 않는 한, 예: 챌린지 값에 따라 자격 증명이 달라지거나 동기화된 시계를 사용하는 경우).

프록시가 요청을 전달할 때 해당 요청의 어떤 Authorization 헤더 필드도 수정해서는 MUST NOT 합니다. 인증된 요청에 대한 응답을 저장하는 방법 및 Authorization 헤더 필드 처리에 관한 요구사항은 섹션 3.5 of [CACHING]를 참조하십시오.

HTTP 인증 스킴은 클라이언트의 인증 자격 증명이 수락된 이후 서버가 정보를 전달하기 위해 "Authentication-Info" 응답 필드를 사용할 수 있습니다. 이 정보에는 서버의 최종화 메시지(예: 서버 인증)가 포함될 수 있습니다.

필드 값은 섹션 11.3에 정의된 "auth-param" 문법을 사용하는 매개변수(이름/값 쌍) 목록입니다. 이 명세서는 일반 형식만 설명하며, Authentication-Info를 사용하는 인증 스킴은 개별 매개변수를 정의합니다. 예를 들어 "Digest" 인증 스킴은 RFC7616 섹션 3.5에서 여러 매개변수를 정의합니다.

  Authentication-Info = #auth-param

Authentication-Info 필드는 요청 메서드나 상태 코드와 무관하게 어떤 HTTP 응답에서도 사용할 수 있습니다. 그 의미는 해당 요청의 Authorization 헤더 필드(섹션 11.6.2)가 나타내는 인증 스킴에 의해 정의됩니다.

프록시가 응답을 전달할 때 필드 값을 어떤 방식으로든 수정하는 것은 허용되지 않습니다.

Authentication-Info는 인증 스킴이 명시적으로 허용하는 경우 트레일러 필드(섹션 6.5)로 전송될 수 있습니다.

"Proxy-Authenticate" 헤더 필드는 이 요청에 대해 프록시에 적용되는 인증 스킴과 매개변수를 나타내는 적어도 하나의 챌린지로 구성됩니다. 프록시는 생성하는 각 407 (Proxy Authentication Required) 응답에 대해 최소 하나의 Proxy-Authenticate 헤더 필드를 전송해야 MUST 합니다.

  Proxy-Authenticate = #challenge

WWW-Authenticate와 달리, Proxy-Authenticate 헤더 필드는 응답 체인에서 다음 아웃바운드 클라이언트에만 적용됩니다. 이는 특정 프록시를 선택한 클라이언트만이 해당 인증에 필요한 자격 증명을 가질 가능성이 높기 때문입니다. 그러나 동일한 관리 도메인 내에서 여러 프록시가 사용되는 경우(예: 대규모 기업 네트워크의 사무실 및 지역 캐싱 프록시), 자격 증명이 사용자 에이전트에 의해 생성되어 계층을 통해 전달되어 소비될 수 있습니다. 따라서 이러한 구성에서는 각 프록시가 동일한 챌린지 집합을 전송하여 Proxy-Authenticate가 전달되는 것처럼 보일 수 있습니다.

WWW-Authenticate에 대한 구문 분석 고려사항이 이 헤더 필드에도 적용된다는 점에 유의하십시오; 자세한 내용은 섹션 11.6.1을 참조하십시오.

"Proxy-Authorization" 헤더 필드는 클라이언트가 인증을 요구하는 프록시에 자신(또는 사용자)을 식별할 수 있게 합니다. 그 값은 프록시 및/또는 요청된 리소스의 realm에 대한 클라이언트의 인증 정보를 포함하는 자격 증명으로 구성됩니다.

  Proxy-Authorization = credentials

Authorization과 달리, Proxy-Authorization 헤더 필드는 인증을 요구한 다음 인바운드 프록시에만 적용됩니다. 프록시 체인이 사용되는 경우 Proxy-Authorization 헤더 필드는 자격 증명을 기대한 첫 번째 인바운드 프록시에 의해 소비됩니다. 프록시는 프록시들이 협력적으로 요청을 인증하는 메커니즘이라면 클라이언트 요청의 자격 증명을 다음 프록시로 중계할 수 MAY 있습니다.

  Proxy-Authentication-Info = #auth-param

그러나 Authentication-Info와 달리, Proxy-Authentication-Info 헤더 필드는 응답 체인에서 다음 아웃바운드 클라이언트에만 적용됩니다. 이는 특정 프록시를 선택한 클라이언트만이 해당 인증에 필요한 자격 증명을 가질 가능성이 높기 때문입니다. 다만, 동일한 관리 도메인 내에서 여러 프록시가 사용되는 구성에서는 사용자 에이전트가 자격 증명을 생성하여 계층을 통해 전달하는 것이 일반적이므로, 각 프록시가 동일한 필드 값을 보낼 경우 Proxy-Authentication-Info가 전달되는 것처럼 보일 수 있습니다.

Proxy-Authentication-Info는 인증 스킴이 명시적으로 허용하는 경우 트레일러 필드(섹션 6.5)로 전송될 수 있습니다.

각 콘텐츠 협상 필드에 대해, 해당 필드를 포함하지 않는 요청은 발신자가 해당 협상 차원에 대해 선호가 없음을 의미합니다.

요청에 콘텐츠 협상 헤더 필드가 포함되어 있고 사용 가능한 응답 표현 중 어느 것도 그 필드에 따라 허용될 수 없다고 간주되는 경우, 출처 서버는 해당 헤더 필드를 존중하여 406 (Not Acceptable) 응답을 보내거나 그 헤더 필드를 무시하여 해당 요청 헤더 필드에 대해 콘텐츠 협상의 대상이 아닌 것처럼 응답을 처리할 수 있습니다. 그러나 이는 클라이언트가 실제로 그 표현을 사용할 수 있다는 것을 보장하지는 않습니다.

이 명세서에서 정의된 콘텐츠 협상 필드들은 공통 매개변수인 "q"(대소문자 구분 없음)를 사용하여 관련 종류의 콘텐츠에 대한 상대적 "가중치"를 지정할 수 있습니다. 이 가중치는 종종 서버 구성에서 리소스에 대해 선택 가능한 다양한 표현의 상대적 품질에 가중치를 부여하는 데 사용되므로 "품질 값(qvalue)"이라고 불립니다.

가중치는 0에서 1 사이의 실수로 정규화되며, 0.001이 가장 덜 선호되고 1이 가장 선호됩니다; 값 0은 "허용되지 않음"을 의미합니다. "q" 파라미터가 없으면 기본 가중치는 1입니다.

  weight = OWS ";" OWS "q=" qvalue
  qvalue = ( "0" [ "." 0*3DIGIT ] )
         / ( "1" [ "." 0*3("0") ] )

qvalue를 전송하는 발신자는 소수점 이하 세 자리를 초과하여 생성해서는 MUST NOT 합니다. 사용자 구성도 동일한 방식으로 제한되어야 합니다.

해당 헤더 필드들 중 대부분은 명시된 경우 미지정 값을 선택하는 와일드카드 값("*")을 정의합니다. 와일드카드가 없으면 필드에 명시적으로 언급되지 않은 값은 허용되지 않는 것으로 간주됩니다. Vary 내에서 와일드카드 값은 분산(variance)이 무제한임을 의미합니다.

"Accept" 헤더 필드는 사용자 에이전트가 응답의 미디어 타입에 관해 자신의 선호도를 지정하는 데 사용할 수 있습니다. 예를 들어 인라인 이미지 요청처럼 요청이 특정한 소수의 원하는 타입으로 제한된 경우 이를 나타내는 데 사용될 수 있습니다.

서버가 응답에 포함하여 전송할 경우, Accept는 동일한 리소스에 대한 이후 요청의 콘텐츠에서 어떤 콘텐츠 타입이 선호되는지에 대한 정보를 제공합니다.

  Accept = #( media-range [ weight ] )

  media-range    = ( "*/*"
                     / ( type "/" "*" )
                     / ( type "/" subtype )
                   ) parameters

별표 "*" 문자는 미디어 타입을 범위로 그룹화하는 데 사용되며, "*/*"는 모든 미디어 타입을, "type/*"는 해당 타입의 모든 서브타입을 나타냅니다. media-range는 해당 범위에 적용 가능한 미디어 타입 파라미터를 포함할 수 있습니다.

각 media-range 뒤에는 선택적으로 적용 가능한 미디어 타입 파라미터(예: charset)가 올 수 있으며, 그 뒤에 상대적 가중치를 나타내는 선택적 "q" 파라미터가 올 수 있습니다(Section 12.4.2).

이전 규격은 가중치 파라미터 뒤에 확장 파라미터가 나타나는 것을 허용했었습니다. accept 확장 문법(accept-params, accept-ext)은 복잡하게 정의되어 있고 실무에서 사용되지 않았으며 새로운 헤더 필드를 통해 더 쉽게 배포될 수 있으므로 제거되었습니다. 가중치를 사용하는 발신자는 "q"를 마지막에 보내는 것이 SHOULD 합니다(모든 media-range 파라미터 뒤). 수신자는 파라미터 순서와 관계없이 이름이 "q"인 어떤 파라미터든 가중치로 처리해야 SHOULD 합니다.

예시

Accept: audio/*; q=0.2, audio/basic

는 "나는 audio/basic을 선호하지만, 이용 가능한 최선의 선택에서 품질을 80%로 할인한 뒤 어떤 audio 타입이라도 보내라"로 해석됩니다.

좀 더 정교한 예시는

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c

말로 표현하면 "text/html 및 text/x-c가 동등하게 선호되며, 이것들이 없으면 text/x-dvi를 보내고, 그것도 없으면 text/plain을 보내라"가 됩니다.

미디어 범위는 더 구체적인 범위나 특정 미디어 타입으로 재정의될 수 있습니다. 주어진 타입에 대해 둘 이상의 media range가 적용되면 가장 구체적인 참조가 우선합니다. 예를 들어,

Accept: text/*, text/plain, text/plain;format=flowed, */*

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

주어진 타입에 연관된 미디어 타입 품질 계수는 해당 타입과 일치하는 가장 높은 우선순위의 media range를 찾아 결정됩니다. 예를 들어,

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

"Accept-Charset" 헤더 필드는 사용자 에이전트가 텍스트 응답 콘텐츠에서 선호하는 문자 집합(charset)을 나타내기 위해 보낼 수 있습니다. 예를 들어, 더 포괄적이거나 특수 목적의 문자 집합을 이해할 수 있는 사용자 에이전트는 해당 기능을 출처 서버에 신호할 수 있습니다.

  Accept-Charset = #( ( token / "*" ) [ weight ] )

문자셋 이름은 섹션 8.3.2에서 정의됩니다. 사용자 에이전트는 각 문자셋에 대해 품질 값을 연결하여 해당 문자셋에 대한 상대적 선호도를 나타낼 수 있습니다(섹션 12.4.2). 예:

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Charset 필드에 "*" 특수 값이 있으면, 이는 필드의 다른 곳에 명시되지 않은 모든 문자셋과 일치합니다.

"Accept-Encoding" 헤더 필드는 콘텐츠 코딩(Section 8.4.1)의 사용에 관한 선호도를 나타내는 데 사용될 수 있습니다.

사용자 에이전트가 요청에서 전송할 때, Accept-Encoding은 응답에서 허용되는 콘텐츠 코딩을 나타냅니다.

서버가 응답에서 전송할 때, Accept-Encoding은 이후 동일 리소스에 대한 요청의 콘텐츠에서 어떤 콘텐츠 코딩이 선호되는지를 나타냅니다.

"identity" 토큰은 "인코딩 없음(no encoding)"의 동의어로 사용되어 인코딩이 없음을 선호할 때 이를 전달합니다.

  Accept-Encoding  = #( codings [ weight ] )
  codings          = content-coding / "identity" / "*"

각 codings 값은 해당 인코딩에 대한 선호도를 나타내는 품질 값(가중치)을 가질 수 있습니다(Section 12.4.2). Accept-Encoding 필드의 "*" 기호는 필드에 명시적으로 나열되지 않은 이용 가능한 콘텐츠 코딩과 일치합니다.

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

1. 요청에 Accept-Encoding 헤더 필드가 없으면, 어떠한 콘텐츠 코딩도 사용자 에이전트에 의해 허용되는 것으로 간주됩니다.
2. 표현에 콘텐츠 코딩이 없으면, Accept-Encoding 헤더 필드가 "identity;q=0" 또는 "*;q=0"을 명시하고 "identity"에 대한 더 구체적인 항목이 없지 않는 한, 기본적으로 허용됩니다.
3. 표현의 콘텐츠 코딩이 Accept-Encoding 필드 값에 나열된 콘텐츠 코딩 중 하나이면, 그 qvalue가 0이 아닌 한 허용됩니다. (섹션 12.4.2에 정의된 대로 qvalue 0은 "허용되지 않음"을 의미합니다.)

표현은 여러 콘텐츠 코딩으로 인코딩될 수 있습니다. 그러나 대부분의 콘텐츠 코딩은 동일한 목적(예: 데이터 압축)을 달성하는 대안적 방법입니다. 동일한 목적을 가진 여러 콘텐츠 코딩 중에서 선택할 때, 가장 높은 비제로 qvalue를 가진 허용 가능한 콘텐츠 코딩이 선호됩니다.

빈 필드 값을 가진 Accept-Encoding 헤더 필드는 사용자 에이전트가 응답에 어떤 콘텐츠 코딩도 원하지 않는다는 것을 의미합니다. 비어 있지 않은 Accept-Encoding 헤더 필드가 요청에 존재하고 사용 가능한 응답 표현 중 어느 것도 나열된 허용 가능한 콘텐츠 코딩을 갖지 않는다면, 출처 서버는 identity 코딩이 허용되지 않은 것으로 표시되지 않는 한 콘텐츠 코딩이 없는 응답을 전송해야 SHOULD 합니다.

응답에 Accept-Encoding 헤더 필드가 존재하면, 그것은 해당 요청에서 리소스가 받아들일 의향이 있던 콘텐츠 코딩을 나타냅니다. 필드 값은 요청에서와 동일한 방식으로 평가됩니다.

이 정보는 연관된 요청에 특정적임에 유의하십시오; 동일 서버의 다른 리소스에 대한 지원 인코딩 집합은 다를 수 있고 시간에 따라 변경되거나 요청의 다른 측면(예: 요청 메서드)에 따라 달라질 수 있습니다.

지원되지 않는 콘텐츠 코딩 때문에 요청이 실패하는 서버는 415 (Unsupported Media Type) 상태로 응답하고 해당 응답에 Accept-Encoding 헤더 필드를 포함하여 클라이언트가 콘텐츠 코딩 관련 문제와 미디어 타입 관련 문제를 구별할 수 있도록 해야 합니다. 미디어 타입과 관련 없는 이유로 415 상태로 요청을 실패시키는 서버는 혼동을 피하기 위해 Accept-Encoding 헤더 필드를 포함해서는 MUST NOT 합니다.

Accept-Encoding의 가장 일반적인 사용은 클라이언트가 낙관적으로 콘텐츠 코딩을 사용했지만 실패한 경우에 대한 415 응답에서입니다. 그러나 이 헤더 필드는 또한 향후 상호작용을 최적화하기 위해 클라이언트에게 콘텐츠 코딩이 지원됨을 알리는 데 사용될 수 있습니다. 예를 들어, 요청 콘텐츠가 압축 사용을 정당화할 만큼 충분히 클 경우 리소스는 2xx 응답에 이를 포함할 수 있습니다.

"Accept-Language" 헤더 필드는 사용자 에이전트가 응답에서 선호하는 자연어 집합을 표시하는 데 사용할 수 있습니다. 언어 태그는 섹션 8.5.1에 정의되어 있습니다.

  Accept-Language = #( language-range [ weight ] )
  language-range  =
            <language-range, see [RFC4647], Section 2.1>

각 language-range에는 그 범위에 지정된 언어에 대한 사용자의 선호 추정치를 나타내는 품질 값을 부여할 수 있습니다(섹션 12.4.2). 예를 들어,

Accept-Language: da, en-gb;q=0.8, en;q=0.7

는 "덴마크어를 선호하지만 영국식 영어와 기타 영어도 허용한다"는 의미입니다.

일부 수신자는 언어 태그가 나열된 순서를 동일한 품질 값을 가진 태그들에 대해 내림차순 우선순위의 표시로 취급하기도 하지만(값이 없으면 q=1과 동일), 이 동작에 의존해서는 안 됩니다. 일관성과 상호운용성을 극대화하기 위해 많은 사용자 에이전트는 각 언어 태그에 고유한 품질 값을 부여하면서 또한 내림차순 품질 순서로 나열합니다. 언어 우선순위 목록에 대한 추가 논의는 RFC4647 섹션 2.3을 참조하십시오.

매칭을 위해서는 RFC4647의 섹션 3이 여러 매칭 스킴을 정의합니다. 구현체는 요구사항에 가장 적합한 매칭 스킴을 제공할 수 있습니다. "기본 필터링(Basic Filtering)" 스킴([RFC4647], RFC4647 섹션 3.3.1)은 이전 HTTP 규격에서 정의된 매칭 스킴과 동일합니다.

사용자의 언어적 이해 가능성은 개인에 크게 의존하므로, 사용자 에이전트는 언어 선호 설정에 대해 사용자가 제어할 수 있도록 해야 합니다(사용자 에이전트 자체의 구성 또는 사용자 제어가 가능한 시스템 설정을 기본으로 함). 이러한 제어를 사용자에게 제공하지 않는 사용자 에이전트는 Accept-Language 헤더 필드를 보내서는 MUST NOT 합니다.

응답의 "Vary" 헤더 필드는 메서드와 대상 URI를 제외한 요청 메시지의 어떤 부분이 이 응답의 콘텐츠 선택 과정에 영향을 미쳤을 수 있는지를 설명합니다.

  Vary = #( "*" / field-name )

Vary 필드 값은 와일드카드 "*"이거나, 이 응답의 표현을 선택하는 데 역할을 했을 수 있는 요청 필드 이름들의 목록(선택 헤더 필드)입니다. 잠재적 선택 헤더 필드는 이 명세서에 정의된 필드에만 국한되지 않습니다.

"*" 멤버를 포함하는 목록은 요청의 다른 측면(예: 클라이언트의 네트워크 주소)을 포함하여 응답 표현 선택에 역할을 했을 수 있음을 알립니다. 수신자는 이 응답이 이후의 요청에 적합한지 결정할 수 없으므로 원점 서버에 요청을 전달하지 않고는 판단할 수 없습니다. 프록시는 Vary 필드 값으로 "*"를 생성해서는 MUST NOT 합니다.

예를 들어, 다음을 포함하는 응답은

Vary: accept-encoding, accept-language

출처 서버가 이 응답의 콘텐츠를 선택할 때 요청의 Accept-Encoding 및 Accept-Language 헤더 필드(또는 그 부재)를 결정 요인으로 사용했을 수 있음을 나타냅니다.

1. 캐시 수신자에게 이 응답을 나중 요청에 재사용하려면 원래 요청과 나중 요청이 나열된 헤더 필드에 대해 동일한 값을 가져야 하며(Section 4.1 of [CACHING] 참조), 그렇지 않으면 출처 서버에 의해 재사용이 검증되어야 MUST NOT 합니다. 즉, Vary는 새로운 요청이 저장된 캐시 항목과 일치하기 위해 필요한 캐시 키를 확장합니다.

2. 사용자 에이전트 수신자에게 이 응답이 콘텐츠 협상의 대상이었음을 알리고(Section 12) 나열된 헤더 필드에 다른 값이 제공되면 이후의 요청에서 다른 표현이 전송될 수 있음을 알립니다(proactive negotiation).

출처 서버는 이후 요청에 대해 이 응답을 선택적으로 재사용하기를 원할 때 캐시 가능한 응답에 Vary 헤더 필드를 생성하는 것이 SHOULD 합니다. 일반적으로 이는 응답 콘텐츠가 선택 헤더 필드에 의해 표현이 맞춤화된 경우에 해당합니다(예: 출처 서버가 요청의 Accept-Language 헤더 필드를 기반으로 응답 언어를 선택한 경우).

Vary는 응답 선택에서의 분산이 캐싱에 미치는 성능 영향보다 덜 중요하다고 출처 서버가 판단할 때 생략될 수 있습니다. 특히 재사용이 이미 캐시 응답 지시자(Section 5.2 of [CACHING])에 의해 제한되는 경우 그러합니다.

Authorization 필드 이름은 해당 응답을 다른 사용자에 대해 재사용하는 것이 금지되어 있으므로 Vary에 포함할 필요가 없습니다(Section 11.6.2). 마찬가지로, 응답 콘텐츠가 네트워크 지역에 의해 선택되었지만 출처 서버가 캐시된 응답을 수신자가 지역을 이동하더라도 재사용되게 하려는 경우, 출처 서버는 Vary에 그러한 분산을 표시할 필요가 없습니다.

"If-Match" 헤더 필드는 필드 값이 "*"일 때 수신자 출처 서버가 대상 리소스의 적어도 하나의 현재 표현을 가지고 있음을 조건으로 하거나, 필드 값에 제공된 엔터티 태그 목록 중 하나와 일치하는 엔터티 태그를 가진 대상 리소스의 현재 표현을 가지고 있음을 조건으로 하여 요청 메서드를 조건화합니다.

출처 서버는 If-Match에 대해 엔터티 태그를 비교할 때 강한 비교 함수를 사용해야 MUST 합니다(Section 8.8.3.2). 클라이언트는 이 선행 조건이 표현 데이터에 어떤 변경이라도 있었을 경우 메서드 적용을 방지하도록 의도했기 때문입니다.

  If-Match = "*" / #entity-tag

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

If-Match는 주로 여러 사용자 에이전트가 동일한 리소스에서 병행으로 작동할 때 우발적인 덮어쓰기를 방지하기 위해 상태 변경 메서드(e.g., POST, PUT, DELETE)와 함께 사용됩니다(즉, "lost update" 문제를 방지). 일반적으로 선택되거나 수정되는 표현이 포함된 모든 메서드에 사용될 수 있으며, 선택된 표현의 현재 엔터티 태그가 If-Match 필드 값의 멤버가 아니면 요청을 중단합니다.

출처 서버가 표현을 선택하는 요청을 수신하고 그 요청에 If-Match 헤더 필드가 포함된 경우, 출처 서버는 메서드를 수행하기 전에 Section 13.2에 따라 If-Match 조건을 평가해야 MUST 합니다.

1. 필드 값이 "*"인 경우, 출처 서버가 대상 리소스에 대한 현재 표현을 가지고 있으면 조건은 참입니다.
2. 필드 값이 엔터티 태그 목록인 경우, 나열된 태그들 중 어느 하나라도 선택된 표현의 엔터티 태그와 일치하면 조건은 참입니다.
3. 그 밖의 경우, 조건은 거짓입니다.

If-Match 조건을 평가한 출처 서버는 그 조건이 거짓으로 평가되면 요청된 메서드를 수행해서는 MUST NOT 합니다. 대신 출처 서버는 조건부 요청이 실패했음을 나타내기 위해 412 (Precondition Failed) 상태 코드로 응답할 수 MAY 있습니다. 또는 요청이 선택된 표현에 이미 적용된 것으로 보이는 상태 변경 연산인 경우, 출처 서버는 사용자 에이전트가 이를 인식하지 못했을 수 있으므로 2xx (Successful) 상태 코드로 응답할 수 MAY 있습니다(예: 이전 응답이 손실되었거나 다른 사용자 에이전트가 동등한 변경을 수행한 경우).

변경 요청이 이미 적용된 것으로 보일 때 출처 서버가 성공 응답을 보내는 것은 많은 저작(use-case)에서 더 효율적이지만, 여러 사용자 에이전트가 매우 유사하지만 협력적이지 않은 변경 요청을 하는 경우 일부 상태 전이가 손실될 위험이 있습니다. 예를 들어 공통 리소스에 대해 원자적이지 않은 증가 연산을 세마포어처럼 사용하는 여러 에이전트는 충돌 가능성이 큽니다. 이런 종류의 리소스에 대해서는 출처 서버가 비안전 메서드의 모든 실패한 선행 조건에 대해 412를 엄격하게 보내는 것이 더 낫습니다. 다른 경우에는 성공 응답에서 ETag 필드를 제외하면 사용자 에이전트가 다음 요청으로 GET을 수행하여 리소스의 현재 상태에 대한 혼동을 해소하도록 유도할 수 있습니다.

클라이언트는 선택된 표현이 일치하지 않을 경우 412 (Precondition Failed) 응답을 선호함을 나타내기 위해 GET 요청에 If-Match 헤더 필드를 전송할 수 MAY 있습니다. 그러나 이것은 부분 표현을 완성하기 위한 범위 요청(Section 14)에서만 유용합니다. If-Range(If-Range, Section 13.1.5)가 클라이언트가 새 표현을 선호할 때 범위 요청에 더 적합합니다.

캐시 또는 중개자는 상호운용성 특징이 출처 서버에만 필요하므로 If-Match를 무시할 수 MAY 있습니다.

If-Match 헤더 필드가 "*"와 다른 값들(다른 "*" 인스턴스 포함)을 동시에 포함하는 목록 값을 갖는 것은 문법적으로 유효하지 않으며(따라서 생성해서는 안 됨) 또한 상호운용성이 없을 가능성이 높습니다.

"If-None-Match" 헤더 필드는 수신자 캐시나 출처 서버가 필드 값이 "*"일 때 대상 리소스에 대한 어떠한 현재 표현도 가지고 있지 않거나, 선택된 표현의 엔터티 태그가 필드 값에 나열된 것들과 일치하지 않는 경우에만 요청 메서드를 허용하도록 조건화합니다.

수신자는 If-None-Match에 대해 엔터티 태그를 비교할 때 약한 비교 함수를 사용해야 MUST 합니다(Section 8.8.3.2). 약한 엔터티 태그는 표현 데이터에 변경이 있더라도 캐시 검증에 사용될 수 있기 때문입니다.

  If-None-Match = "*" / #entity-tag

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

If-None-Match는 주로 조건부 GET 요청에서 캐시된 정보를 최소한의 트랜잭션 오버헤드로 효율적으로 업데이트할 수 있게 사용됩니다. 클라이언트가 엔터티 태그를 가진 하나 이상의 저장된 응답을 업데이트하려는 경우, 클라이언트는 GET 요청을 만들 때 해당 엔터티 태그 목록을 포함하는 If-None-Match 헤더 필드를 생성해야 SHOULD 합니다. 이렇게 하면 수신 서버는 선택된 표현이 저장된 응답 중 하나와 일치할 때 304 (Not Modified) 응답을 보내 이를 나타낼 수 있습니다.

If-None-Match는 또한 값 "*"을 사용하여 클라이언트가 대상 리소스에 현재 표현이 없다고 믿을 때 비안전 요청 메서드(e.g., PUT)가 기존 표현을 우발적으로 수정하는 것을 방지할 수 있습니다(Section 9.2.1). 이는 클라이언트 여러 명이 대상 리소스의 초기 표현을 생성하려고 시도할 때 발생할 수 있는 "lost update" 문제의 변형입니다.

출처 서버가 표현을 선택하는 요청을 수신하고 그 요청에 If-None-Match 헤더 필드가 포함된 경우, 출처 서버는 메서드를 수행하기 전에 Section 13.2에 따라 If-None-Match 조건을 평가해야 MUST 합니다.

1. 필드 값이 "*"인 경우, 출처 서버가 대상 리소스에 대한 현재 표현을 가지고 있으면 조건은 거짓입니다.
2. 필드 값이 엔터티 태그 목록인 경우, 나열된 태그들 중 하나가 선택된 표현의 엔터티 태그와 일치하면 조건은 거짓입니다.
3. 그 밖의 경우, 조건은 참입니다.

If-None-Match 조건을 평가한 출처 서버는 그 조건이 거짓으로 평가되면 요청된 메서드를 수행해서는 MUST NOT 합니다; 대신 출처 서버는 다음 중 하나로 응답해야 MUST 합니다: a) 요청 메서드가 GET 또는 HEAD인 경우 304 (Not Modified) 상태 코드, 또는 b) 다른 모든 요청 메서드에 대해서는 412 (Precondition Failed) 상태 코드.

수신된 If-None-Match 헤더 필드의 캐시 처리에 대한 요구사항은 Section 4.3.2 of [CACHING]에 정의되어 있습니다.

If-None-Match 헤더 필드가 "*"와 다른 값들(다른 "*" 인스턴스 포함)을 동시에 포함하는 목록 값을 갖는 것은 문법적으로 유효하지 않으며(따라서 생성해서는 안 됨) 또한 상호운용성이 없을 가능성이 높습니다.

"If-Modified-Since" 헤더 필드는 GET 또는 HEAD 요청 메서드를 선택된 표현의 수정 날짜가 필드 값으로 제공된 날짜보다 더 최근인 경우에만 수행되도록 조건화합니다. 선택된 표현의 데이터 전송은 해당 데이터가 변경되지 않았다면 회피됩니다.

  If-Modified-Since = HTTP-date

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

수신자는 요청이 If-None-Match 헤더 필드를 포함하는 경우 If-Modified-Since를 무시해야 MUST 합니다; If-None-Match의 조건이 If-Modified-Since 조건보다 더 정확한 대체로 간주되며, 두 필드는 If-None-Match를 구현하지 않을 수 있는 오래된 중개자와의 상호운용성을 위해서만 결합됩니다.

수신자는 If-Modified-Since 헤더 필드의 값이 유효한 HTTP-date가 아니거나 필드 값이 둘 이상 존재하거나 요청 메서드가 GET 또는 HEAD가 아닌 경우 If-Modified-Since를 무시해야 MUST 합니다.

수신자는 리소스에 수정 날짜가 제공되지 않는 경우 If-Modified-Since 헤더 필드를 무시해야 MUST 합니다.

수신자는 If-Modified-Since 필드 값의 타임스탬프를 출처 서버의 시계 기준으로 해석해야 MUST 합니다.

If-Modified-Since는 일반적으로 두 가지 목적에 사용됩니다: 1) 엔터티 태그가 없는 캐시된 표현의 효율적인 업데이트를 허용하기 위해, 2) 웹 탐색 범위를 최근에 변경된 리소스로 제한하기 위해.

캐시 업데이트에 사용될 때, 캐시는 보통 캐시된 메시지의 Last-Modified 헤더 필드 값을 사용하여 If-Modified-Since의 필드 값을 생성합니다. 이 동작은 시계가 잘 동기화되지 않았거나 서버가 정확한 타임스탬프 일치를 선호할 때 가장 상호운용적입니다(예: 출처 서버의 시계가 수정되었거나 표현이 아카이브 백업에서 복원된 경우 Last-Modified 날짜가 "과거로 돌아가는" 문제가 발생할 수 있음). 그러나 캐시는 캐시된 메시지에 Last-Modified 헤더 필드가 없는 경우 수신 시의 Date 헤더 필드나 메시지를 받은 시각 같은 다른 데이터를 기반으로 필드 값을 생성하기도 합니다.

최근 시간 창으로 검색 범위를 제한하는 데 사용될 때, 사용자 에이전트는 자신의 시계나 이전 응답에서 서버로부터 받은 Date 헤더 필드를 기반으로 If-Modified-Since 값을 생성합니다. 선택된 표현의 Last-Modified 헤더 필드에 기반한 엄격한 타임스탬프 일치를 선택하는 출처 서버는 지정된 창 동안에 변경된 항목만 사용자 에이전트가 제한하도록 도울 수 없습니다.

출처 서버가 표현을 선택하는 요청을 수신하고 그 요청에 If-None-Match 헤더 필드 없이 If-Modified-Since 헤더 필드가 포함된 경우, 출처 서버는 메서드를 수행하기 전에 If-Modified-Since 조건을 Section 13.2에 따라 평가하는 것이 SHOULD 합니다.

1. 선택된 표현의 마지막 수정 날짜가 필드 값으로 제공된 날짜보다 이전이거나 같다면, 조건은 거짓입니다.
2. 그렇지 않으면, 조건은 참입니다.

If-Modified-Since 조건을 평가한 출처 서버는 조건이 거짓으로 평가되면 요청된 메서드를 수행해서는 SHOULD NOT 하며, 대신 이전에 캐시된 응답을 식별하거나 업데이트하는 데 유용한 메타데이터만 포함하는 304 (Not Modified) 응답을 생성해야 SHOULD 합니다.

수신된 If-Modified-Since 헤더 필드의 캐시 처리에 대한 요구사항은 Section 4.3.2 of [CACHING]에 정의되어 있습니다.

"If-Unmodified-Since" 헤더 필드는 요청 메서드를 선택된 표현의 마지막 수정 날짜가 필드 값으로 제공된 날짜보다 이전이거나 같을 경우에만 수행하도록 조건화합니다. 이 필드는 사용자 에이전트가 표현에 대한 엔터티 태그를 가지고 있지 않은 경우 If-Match와 동일한 목적을 달성합니다.

  If-Unmodified-Since = HTTP-date

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

수신자는 요청에 If-Match 헤더 필드가 포함된 경우 If-Unmodified-Since를 무시해야 MUST 합니다; If-Match의 조건이 If-Unmodified-Since 조건보다 더 정확한 대체로 간주되며, 두 필드는 If-Match를 구현하지 않을 수 있는 오래된 중개자와의 상호운용성을 위해서만 결합됩니다.

수신자는 If-Unmodified-Since 헤더 필드의 값이 유효한 HTTP-date가 아니거나(값이 날짜 목록처럼 보이는 경우 포함)면 If-Unmodified-Since를 무시해야 MUST 합니다.

수신자는 리소스에 수정 날짜가 제공되지 않는 경우 If-Unmodified-Since 헤더 필드를 무시해야 MUST 합니다.

수신자는 If-Unmodified-Since 필드 값의 타임스탬프를 출처 서버의 시계 기준으로 해석해야 MUST 합니다.

If-Unmodified-Since는 리소스가 표현에 엔터티 태그를 제공하지 않는 경우에 여러 사용자 에이전트가 병행으로 작동할 때 우발적인 덮어쓰기를 방지하기 위해 상태 변경 메서드(e.g., POST, PUT, DELETE)와 함께 가장 자주 사용됩니다(즉, "lost update" 문제 방지). 일반적으로 이는 선택되거나 수정되는 표현이 포함된 모든 메서드에 사용되어 선택된 표현의 마지막 수정 날짜가 If-Unmodified-Since 값 이후로 변경되었을 경우 요청을 중단합니다.

출처 서버가 표현을 선택하는 요청을 수신하고 그 요청에 If-Unmodified-Since 헤더 필드가 포함되었지만 If-Match 헤더 필드는 없는 경우, 출처 서버는 메서드를 수행하기 전에 Section 13.2에 따라 If-Unmodified-Since 조건을 평가해야 MUST 합니다.

1. 선택된 표현의 마지막 수정 날짜가 필드 값으로 제공된 날짜보다 이전이거나 같으면, 조건은 참입니다.
2. 그렇지 않으면, 조건은 거짓입니다.

If-Unmodified-Since 조건을 평가한 출처 서버는 그 조건이 거짓으로 평가되면 요청된 메서드를 수행해서는 MUST NOT 합니다. 대신 출처 서버는 조건부 요청이 실패했음을 나타내기 위해 412 (Precondition Failed) 상태 코드로 응답할 수 MAY 있습니다. 또는 요청이 선택된 표현에 이미 적용된 것으로 보이는 상태 변경 연산인 경우, 출처 서버는 사용자 에이전트가 이를 인식하지 못했을 수 있으므로 2xx (Successful) 상태 코드로 응답할 수 MAY 있습니다.

변경 요청이 이미 적용된 것으로 보일 때 출처 서버가 성공 응답을 보내는 것은 많은 저작(use-case)에서 더 효율적이지만, 여러 사용자 에이전트가 매우 유사하지만 협력적이지 않은 변경 요청을 하는 경우 일부 위험이 있습니다. 그런 경우 출처 서버는 비안전 메서드의 모든 실패한 선행 조건에 대해 412를 엄격하게 보내는 것이 더 낫습니다.

클라이언트는 선택된 표현이 수정되었을 경우 412 (Precondition Failed) 응답을 선호함을 나타내기 위해 GET 요청에 If-Unmodified-Since 헤더 필드를 전송할 수 MAY 있습니다. 그러나 이것은 범위 요청(Section 14)에서만 유용하며, If-Range(If-Range, Section 13.1.5)가 클라이언트가 새 표현을 선호할 때 범위 요청에 더 적합합니다.

캐시 또는 중개자는 상호운용성 기능이 출처 서버에만 필요하므로 If-Unmodified-Since를 무시할 수 MAY 있습니다.

"If-Range" 헤더 필드는 If-Match 및 If-Unmodified-Since 헤더 필드와 유사하지만 특별한 조건부 요청 메커니즘을 제공하며, 밸리데이터가 일치하지 않으면 수신자에게 Range 헤더 필드를 무시하도록 지시하여 412 (Precondition Failed) 응답 대신 새 선택된 표현의 전체 전송이 일어나게 합니다.

클라이언트에게 표현의 부분 복사본이 있고 전체 표현의 최신 복사본을 원할 경우, 조건부 GET과 함께 Range 헤더 필드를 사용할 수 있습니다(예: If-Unmodified-Since 및/또는 If-Match 중 하나 또는 둘을 사용). 그러나 선행 조건이 표현이 수정되었기 때문에 실패하면, 클라이언트는 전체 현재 표현을 얻기 위해 두 번째 요청을 해야 합니다.

"If-Range" 헤더 필드는 클라이언트가 두 번째 요청을 "단축"할 수 있게 합니다. 비공식적으로 그 의미는 다음과 같습니다: 표현이 변경되지 않았다면 내가 Range로 요청한 부분들을 보내고, 그렇지 않으면 전체 표현을 보내라.

  If-Range = entity-tag / HTTP-date

유효한 entity-tag은 처음 세 문자에서 DQUOTE를 검사하여 유효한 HTTP-date와 구별할 수 있습니다.

클라이언트는 Range 헤더 필드를 포함하지 않는 요청에서 If-Range 헤더 필드를 생성해서는 MUST NOT 합니다. 서버는 Range 헤더 필드를 포함하지 않는 요청에서 수신된 If-Range 헤더 필드를 무시해야 MUST 합니다. 출처 서버는 Range 요청을 지원하지 않는 대상 리소스에 대해 수신된 If-Range 헤더 필드를 무시해야 MUST 합니다.

클라이언트는 엔터티 태그가 약한 것으로 표시된 If-Range 헤더 필드를 생성해서는 MUST NOT 합니다. 클라이언트는 해당 표현에 대한 엔터티 태그가 없고 그 날짜가 Section 8.8.2.2에 정의된 의미에서 강한 밸리데이터인 경우가 아니면 HTTP-date를 포함하는 If-Range 헤더 필드를 생성해서는 MUST NOT 합니다.

서버는 Range 요청에서 If-Range 헤더 필드를 수신하면, 메서드를 수행하기 전에 Section 13.2에 따라 조건을 평가해야 MUST 합니다.

1. 제공된 HTTP-date 밸리데이터가 Section 8.8.2.2에 정의된 의미에서 강한 밸리데이터가 아니면, 조건은 거짓입니다.
2. 제공된 HTTP-date 밸리데이터가 선택된 표현의 Last-Modified 필드 값과 정확히 일치하면, 조건은 참입니다.
3. 그렇지 않으면, 조건은 거짓입니다.

1. 제공된 entity-tag 밸리데이터가 강한 비교 함수(Section 8.8.3.2)를 사용하여 선택된 표현의 ETag 필드 값과 정확히 일치하면, 조건은 참입니다.
2. 그렇지 않으면, 조건은 거짓입니다.

If-Range 헤더 필드의 수신자는 If-Range 조건이 거짓으로 평가되면 Range 헤더 필드를 무시해야 MUST 합니다. 그렇지 않으면 수신자는 요청된 대로 Range 헤더 필드를 처리해야 SHOULD 합니다.

If-Range 비교는 HTTP-date인 경우를 포함하여 정확한 일치로 수행된다는 점을 주의하십시오. 따라서 이는 If-Unmodified-Since 조건을 평가할 때 사용되는 "이전이거나 같음" 비교와 다릅니다.

아래에 제외된 경우를 제외하고, 수신자 캐시 또는 출처 서버는 정상적인 요청 검사를 성공적으로 수행한 후, 요청 콘텐츠(있는 경우)를 처리하거나 요청 메서드와 관련된 작업을 수행하기 직전에 수신된 요청 선행 조건을 평가해야 MUST 합니다. 서버는 조건 없이 동일한 요청에 대해 요청 콘텐츠를 처리하기 전에의 응답이 2xx (Successful) 또는 412 (Precondition Failed) 이외의 상태 코드였을 경우 모든 수신 선행 조건을 무시해야 MUST 합니다. 다시 말해, 중요한 처리가 발생하기 전에 감지할 수 있는 리디렉션과 실패가 선행 조건 평가보다 우선합니다.

대상 리소스의 출처 서버가 아니어서 대상 리소스에 대한 요청을 위한 캐시로서 작동할 수 없는 서버는 이 명세서에서 정의한 조건부 요청 헤더 필드를 평가해서는 MUST NOT 하며, 요청이 전달되는 경우 이를 전달해야 MUST 합니다. 클라이언트는 해당 필드들이 현재 표현을 제공할 수 있는 서버에 의해 평가되기를 의도했기 때문입니다. 마찬가지로, 서버는 CONNECT, OPTIONS 또는 TRACE와 같이 선택된 표현의 선택 또는 수정을 수반하지 않는 요청 메서드와 함께 수신된 이 명세서에서 정의된 조건부 요청 헤더 필드를 무시해야 MUST 합니다.

프로토콜 확장은 선행 조건이 평가되는 조건이나 그 평가의 결과를 수정할 수 있습니다. 예를 들어 immutable 캐시 지시자([RFC8246])는 캐시가 신선한 응답을 보유하고 있을 때 조건부 요청을 전달하지 않도록 지시합니다.

조건부 요청 헤더 필드는 HEAD 메서드와 함께 사용 가능하도록 정의되어 있습니다(HEAD의 의미를 GET과 일관되게 유지하기 위해) — 다만 조건부 HEAD를 전송하는 것은 의미가 없습니다. 성공 응답은 304 (Not Modified) 응답과 동일한 크기이고 412 (Precondition Failed) 응답보다 더 유용합니다.

요청에 둘 이상의 조건부 요청 헤더 필드가 존재할 때, 필드들이 평가되는 순서가 중요해집니다. 실무에서는 "lost update" 선행 조건이 캐시 검증보다 더 엄격한 요구사항을 가지며, 검증된 캐시는 부분 응답보다 더 효율적이고, 엔터티 태그가 날짜 밸리데이터보다 더 정확하다고 여겨지기 때문에 이 문서에서 정의된 필드들이 단일 논리적 순서로 일관되게 구현됩니다.

1. 수신자가 출처 서버이고 If-Match가 존재하는 경우, If-Match 선행 조건을 평가합니다:

   • 참이면, 3단계(3)로 계속합니다
   • 거짓이면, 상태 변경 요청이 이미 성공했는지 판단할 수 없는 한 412 (Precondition Failed)로 응답합니다(자세한 내용은 Section 13.1.1 참조).

2. 수신자가 출처 서버이고 If-Match가 없고 If-Unmodified-Since가 존재하는 경우, If-Unmodified-Since 선행 조건을 평가합니다:

   • 참이면, 3단계(3)로 계속합니다
   • 거짓이면, 상태 변경 요청이 이미 성공했는지 판단할 수 없는 한 412 (Precondition Failed)로 응답합니다(자세한 내용은 Section 13.1.4 참조).

3. If-None-Match가 존재하는 경우, If-None-Match 선행 조건을 평가합니다:

   • 참이면, 5단계(5)로 계속합니다
   • 거짓이면 GET/HEAD의 경우 304 (Not Modified)로 응답합니다
   • 거짓이면 다른 메서드의 경우 412 (Precondition Failed)로 응답합니다

4. 메서드가 GET 또는 HEAD이고 If-None-Match가 없고 If-Modified-Since가 존재하는 경우, If-Modified-Since 선행 조건을 평가합니다:

   • 참이면, 5단계(5)로 계속합니다
   • 거짓이면 304 (Not Modified)로 응답합니다

5. 메서드가 GET이고 Range와 If-Range가 모두 존재하는 경우, If-Range 선행 조건을 평가합니다:

   • 참이고 Range가 선택된 표현에 적용 가능한 경우 206 (Partial Content)로 응답합니다
   • 그렇지 않으면 Range 헤더 필드를 무시하고 200 (OK)로 응답합니다

6. 그 외의 경우,

   • 요청된 메서드를 수행하고 그 성공 또는 실패에 따라 응답합니다.

HTTP에 대한 확장은 이 문서에 정의된 필드들과 실무에서 발견될 수 있는 다른 조건부 필드들에 대해 그러한 필드들을 평가하는 순서를 정의해야 합니다.

범위는 범위 단위와 범위 지정자 집합으로 표현됩니다. 범위 단위 이름은 해당 단위에 적용 가능한 범위 지정자 종류를 결정합니다. 따라서 다음 문법은 일반적입니다: 각 range unit은 언제 int-range, suffix-range, 및 other-range가 허용되는지를 지정해야 합니다.

범위 요청은 단일 범위 또는 단일 표현 내의 여러 범위를 지정할 수 있습니다.

  ranges-specifier = range-unit "=" range-set
  range-set        = 1#range-spec
  range-spec       = int-range
                   / suffix-range
                   / other-range

int-range은 두 개의 음이 아닌 정수로 표현되거나 하나의 음이 아닌 정수부터 표현 데이터의 끝까지를 나타내는 범위입니다. 범위 단위는 정수들이 무엇을 의미하는지(예: 시작부터의 단위 오프셋, 포함 번호 매겨진 부분 등)를 지정합니다.

  int-range     = first-pos "-" [ last-pos ]
  first-pos     = 1*DIGIT
  last-pos      = 1*DIGIT

int-range는 last-pos 값이 존재하고 그것이 first-pos보다 작을 경우 무효입니다.

suffix-range는 제공된 음이 아닌 정수 최대 길이(범위 단위에서)의 접미사로 표현되는 범위입니다. 다시 말해 표현 데이터의 마지막 N 단위입니다.

  suffix-range  = "-" suffix-length
  suffix-length = 1*DIGIT

확장성을 제공하기 위해, other-range 규칙은 애플리케이션별 또는 미래의 범위 단위가 추가 범위 지정자를 정의할 수 있도록 거의 제약이 없는 문법을 허용합니다.

  other-range   = 1*( %x21-2B / %x2D-7E )
                ; 1*(VCHAR excluding comma)

ranges-specifier에 무효이거나 해당 range-unit에 대해 정의되지 않은 어떤 range-spec가 포함되어 있으면 그 ranges-specifier는 무효입니다.

유효한 ranges-specifier는 적어도 하나의 해당 range-unit에 대해 정의된 만족 가능한 range-spec을 포함하는 경우 satisfiable로 간주됩니다. 그렇지 않으면 unsatisfiable입니다.

"bytes" 범위 단위는 표현 데이터의 옥텟(바이트) 시퀀스의 하위 범위를 표현하는 데 사용됩니다. 각 바이트 범위는 표현 데이터의 시작(int-range) 또는 끝(suffix-range)을 기준으로 한 오프셋에서의 정수 범위로 표현됩니다. 바이트 범위는 other-range 지정자를 사용하지 않습니다.

bytes int-range의 first-pos 값은 범위 내 첫 바이트의 오프셋을 제공합니다. last-pos 값은 범위 내 마지막 바이트의 오프셋을 제공합니다; 즉 지정된 바이트 위치는 포함적입니다. 바이트 오프셋은 0에서 시작합니다.

표현 데이터에 콘텐츠 인코딩이 적용된 경우, 각 바이트 범위는 디코딩 후 얻어지는 기본 바이트 시퀀스가 아니라 인코딩된 바이트 시퀀스를 기준으로 계산됩니다.

• 처음 500 바이트(바이트 오프셋 0-499, 포함):

  bytes=0-499
  

• 두 번째 500 바이트(바이트 오프셋 500-999, 포함):

  bytes=500-999
  

클라이언트는 선택된 표현의 길이를 알지 못하더라도 요청하는 바이트 수를 제한할 수 있습니다. last-pos 값이 없거나 그 값이 현재 표현 길이보다 크거나 같으면 바이트 범위는 표현의 나머지로 해석됩니다(즉, 서버는 last-pos 값을 선택된 표현의 현재 길이보다 하나 작은 값으로 대체합니다).

클라이언트는 suffix-range를 사용하여 선택된 표현의 마지막 N 바이트(N > 0)를 참조할 수 있습니다. 선택된 표현이 지정된 suffix-length보다 짧으면 전체 표현이 사용됩니다.

• 마지막 500 바이트(바이트 오프셋 9500-9999, 포함):

  bytes=-500
  

  또는:

  bytes=9500-
  

• 처음과 마지막 바이트만(바이트 0 및 9999):

  bytes=0-0,-1
  

• 처음, 중간, 마지막 각각 1000 바이트:

  bytes= 0-999, 4500-5499, -1000
  

• 두 번째 500 바이트(바이트 오프셋 500-999, 포함)의 다른 유효한(하지만 정규형이 아닌) 명세:

  bytes=500-600,601-999
  bytes=500-700,601-999
  

• 선택된 표현의 현재 길이보다 작은 first-pos를 갖는 int-range, 또는
• 비제로 suffix-length을 갖는 suffix-range.

선택된 표현의 길이가 0일 때, GET 요청에서 만족 가능한 형태의 range-spec은 비제로 suffix-length을 갖는 suffix-range뿐입니다.

바이트-범위 문법에서 first-pos, last-pos, 및 suffix-length은 옥텟의 십진수로 표현됩니다. 콘텐츠 길이에 대한 사전 정의된 제한이 없으므로, 수신자는 잠재적으로 큰 십진수에 대비하고 정수 변환 오버플로로 인한 파싱 오류를 방지해야 MUST 합니다.

100 (Continue) 상태 코드는 요청의 초기 부분이 수신되었고 아직 서버에 의해 거부되지 않았다는 것을 나타냅니다. 서버는 요청이 완전히 수신되어 처리된 후 최종 응답을 보낼 의도가 있습니다.

요청에 Expect 헤더 필드가 포함되어 있고 그 안에 100-continue 기대가 있으면, 100 응답은 서버가 요청 본문을 받기를 원함을 나타냅니다(자세한 내용은 Section 10.1.1 참조). 클라이언트는 요청을 계속 전송하고 100 응답은 폐기하는 것이 바람직합니다.

요청에 Expect 헤더 필드가 없었다면 클라이언트는 이 중간 응답을 단순히 폐기할 수 있습니다.

101 (Switching Protocols) 상태 코드는 서버가 Upgrade 헤더 필드(Section 7.8)를 통해 클라이언트의 요청을 이해하고 준수하여 이 연결에서 사용되는 응용 프로토콜을 변경하겠다는 의사를 나타낼 때 사용됩니다. 서버는 응답에 어떤 프로토콜이 이 응답 후에 유효할지 나타내는 Upgrade 헤더 필드를 생성해야 MUST 합니다.

서버는 이 프로토콜 전환이 유리할 때만 동의할 것으로 가정됩니다. 예를 들어, 오래된 버전보다 새 HTTP 버전으로 전환하는 것이 유리할 수 있고, 실시간 동기화 프로토콜로 전환하는 것이 적합한 경우도 있습니다.

CONNECT에 대한 응답을 제외하고, 200 응답은 메시지 프레이밍이 명시적으로 콘텐츠 길이가 0이라고 표시하지 않는 한 메시지 콘텐츠를 포함하는 것이 기대됩니다. 성공 시 콘텐츠 없음 선호를 요청하는 측면이 있다면 출처 서버는 대신 204 (No Content) 응답을 보내는 것이 바람직합니다. CONNECT의 경우 성공 결과가 터널이므로 200 응답 이후 즉시 터널이 시작되어 콘텐츠가 없습니다.

200 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

GET 또는 HEAD에 대한 200 응답에서 출처 서버는 선택된 표현에 대해 사용 가능한 밸리데이터 필드(Section 8.8)를 전송하는 것이 SHOULD 합니다. 강한 엔터티 태그와 Last-Modified 날짜를 함께 제공하는 것이 선호됩니다.

상태 변경 메서드에 대한 200 응답에서 전송되는 밸리데이터 필드는 요청을 성공적으로 적용한 결과로 형성된 새 표현의 현재 밸리데이터를 전달합니다. PUT 메서드(Section 9.3.4)는 이러한 밸리데이터 전송을 제한할 수 있는 추가 요구사항이 있음을 유의하십시오.

201 (Created) 상태 코드는 요청이 이행되어 하나 이상 새 리소스가 생성되었음을 나타냅니다. 요청으로 생성된 주요 리소스는 응답의 Location 헤더 필드로 식별되거나, Location 헤더가 없으면 대상 URI로 식별됩니다.

201 응답 콘텐츠는 일반적으로 생성된 리소스들을 설명하고 링크합니다. 응답에 전송된 밸리데이터 필드(Section 8.8)는 요청으로 생성된 새 표현에 대한 현재 밸리데이터를 전달합니다. PUT 메서드(Section 9.3.4)는 이러한 밸리데이터 전송을 제한할 수 있는 추가 요구사항이 있음을 유의하십시오.

202 (Accepted) 상태 코드는 요청이 처리 대상으로 접수되었지만 처리가 완료되지 않았음을 나타냅니다. 요청이 실제로 처리될지 여부는 처리가 실제로 일어날 때 허용되지 않을 수 있으므로 확정적이지 않습니다. HTTP에는 비동기 작업의 상태 코드를 재전송하는 수단이 없습니다.

202 응답은 의도적으로 비확정적입니다. 이는 서버가 요청을 어떤 다른 프로세스(예: 하루에 한 번만 실행되는 배치 프로세스)에 위임하면서 사용자 에이전트의 연결이 그 프로세스 완료까지 유지될 필요가 없도록 허용하기 위한 목적입니다. 이 응답과 함께 전송되는 표현은 요청의 현재 상태를 설명하고 요청이 언제 이행될지 추정치를 제공할 수 있는 상태 모니터를 가리키거나 포함해야 합니다.

203 (Non-Authoritative Information) 상태 코드는 요청이 성공했지만 포함된 콘텐츠가 변환 프록시(Section 7.7)에 의해 원본 서버의 200 (OK) 응답과 다르게 수정되었음을 나타냅니다. 이 상태 코드는 프록시가 변환을 적용했음을 수신자에게 알릴 수 있게 하며, 이는 이후 콘텐츠에 대한 결정을 내리는 데 영향을 줄 수 있습니다. 예를 들어, 향후 캐시 검증 요청은 동일한 요청 경로(동일한 프록시를 경유)에서만 적용될 수 있습니다.

203 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

204 (No Content) 상태 코드는 서버가 요청을 성공적으로 이행했으며 응답 본문에 추가로 보낼 콘텐츠가 없음을 나타냅니다. 응답 헤더 필드의 메타데이터는 요청된 동작이 적용된 후의 대상 리소스 및 그 선택된 표현을 참조합니다.

예를 들어, PUT 요청에 대한 응답으로 204 상태 코드가 수신되고 응답에 ETag 필드가 포함되어 있으면, PUT이 성공했으며 ETag 필드 값은 해당 대상 리소스의 새 표현에 대한 엔터티 태그를 포함합니다.

204 응답은 서버가 대상 리소스에 동작을 성공적으로 적용했음을 나타내면서 사용자 에이전트가 현재의 "문서 보기"(있을 경우)에서 벗어날 필요가 없음을 의미합니다. 서버는 사용자 에이전트가 자체 인터페이스에 따라 성공을 사용자에게 알리고 응답의 새 또는 업데이트된 메타데이터를 활성 표현에 적용할 것이라고 가정합니다.

예를 들어 204 상태 코드는 "저장" 동작에 해당하는 문서 편집 인터페이스에서 자주 사용되어 사용자가 저장한 문서를 계속 편집할 수 있게 합니다. 또한 분산 버전 관리 시스템처럼 자동화된 데이터 전송이 빈번할 것으로 예상되는 인터페이스에서도 자주 사용됩니다.

204 응답은 헤더 섹션의 끝에서 종료되며 콘텐츠나 트레일러를 포함할 수 없습니다.

204 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

205 (Reset Content) 상태 코드는 서버가 요청을 이행했으며 요청을 보낸 "문서 보기"를 원래 상태(출처 서버로부터 받은 상태)로 재설정하도록 사용자 에이전트에게 요청함을 나타냅니다.

이 응답은 폼, 메모장, 캔버스 등 데이터 입력을 지원하는 콘텐츠를 받은 사용자가 데이터를 입력하거나 조작하고 그 데이터를 요청으로 제출한 다음 다음 입력을 위해 입력 메커니즘을 재설정하는 일반적인 데이터 입력 사용 사례를 지원하기 위한 것입니다.

205 상태 코드는 추가 콘텐츠가 제공되지 않음을 의미하므로 서버는 205 응답에서 콘텐츠를 생성해서는 MUST NOT 합니다.

206 (Partial Content) 상태 코드는 서버가 대상 리소스에 대한 범위 요청을 성공적으로 이행하여 선택된 표현의 하나 이상의 부분을 전송하고 있음을 나타냅니다.

범위 요청을 지원하는 서버(Section 14)는 보통 요청된 모든 범위를 만족시키려 시도합니다. 왜냐하면 더 적은 데이터를 전송하면 클라이언트가 나머지를 위해 추가 요청을 보낼 가능성이 높기 때문입니다. 그러나 서버는 임시적인 불가용, 캐시 효율성, 부하 분산 등 자체 사유로 요청된 데이터의 일부만 전송하려 할 수 있습니다. 206 응답은 자체 설명적이므로 클라이언트는 범위 요청을 부분적으로만 만족시키는 응답도 이해할 수 있습니다.

클라이언트는 206 응답의 Content-Type과 Content-Range 필드를 검사하여 어떤 부분이 포함되었는지 및 추가 요청이 필요한지 판단해야 MUST 합니다.

206 응답을 생성하는 서버는 다음 섹션들에서 요구하는 것들 외에 동일한 요청에 대해 200 (OK) 응답에서 전송했을 필드들이 해당되는 경우 다음 헤더 필드를 생성해야 MUST 합니다: Date, Cache-Control, ETag, Expires, Content-Location, 및 Vary.

206 응답에 있는 Content-Length 헤더 필드는 이 메시지의 콘텐츠 바이트 수를 나타내며, 일반적으로 선택된 표현의 전체 길이는 아닙니다. 각 Content-Range 헤더 필드는 선택된 표현의 전체 길이에 대한 정보를 포함합니다.

If-Range 헤더 필드가 있는 요청에 대해 206 응답을 생성하는 발신자는 클라이언트가 이전 응답에 이미 포함된 헤더 필드를 가지고 있으므로 다른 표현 헤더 필드를 생성해서는 SHOULD NOT 합니다. 그렇지 않으면 발신자는 동일한 요청에 대해 200 (OK) 응답에서 전송되었을 모든 표현 헤더 필드를 생성해야 MUST 합니다.

206 응답은 휴리스틱하게 캐시 가능하며, 즉 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

300 (Multiple Choices) 상태 코드는 대상 리소스가 여러 표현을 가지며 각 표현이 고유한 더 구체적인 식별자를 가지고 있다는 것을 나타냅니다. 서버는 대체 항목들에 대한 정보를 제공하여 사용자(또는 에이전트)가 하나 이상의 식별자로 요청을 리다이렉트하여 선호 표현을 선택하도록 유도합니다. 즉, 서버는 사용자 에이전트가 가장 적합한 표현을 선택하도록 반응적 협상(Section 12)에 참여하기를 원합니다.

서버에 선호 선택이 있으면, 서버는 선호 선택의 URI 참조를 포함하는 Location 헤더 필드를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 자동 리다이렉션을 위해 Location 필드 값을 사용할 수 MAY 있습니다.

HEAD 이외의 요청 메서드에 대해서는 서버는 300 응답에 표현 메타데이터와 URI 참조 목록이 포함된 콘텐츠를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 제공된 미디어 타입을 이해하면 그 목록에서 자동으로 선택할 수 MAY 있습니다. 자동 선택을 위한 구체적 형식은 이 명세서에서 정의하지 않습니다. 실제로 표현은 사용자 에이전트에 수용 가능할 것으로 판단되는 쉽게 파싱 가능한 형식이나 일반적으로 수용되는 하이퍼텍스트 형식으로 제공됩니다.

300 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

301 (Moved Permanently) 상태 코드는 대상 리소스에 새 영구 URI가 할당되었음을 나타내며, 이후 해당 리소스에 대한 모든 참조는 서버가 전송한 새 URI들 중 하나를 사용해야 합니다. 서버는 링크 편집 기능을 가진 사용자 에이전트가 대상 URI에 대한 참조를 새 참조로 영구 교체할 것을 제안할 수 있습니다. 그러나 이 제안은 일반적으로 무시됩니다(사용자가 실제로 참조 편집을 하고 있고 연결이 안전하며 출처 서버가 편집 대상 콘텐츠의 신뢰할 수 있는 권한자일 때를 제외).

서버는 응답에 새 영구 URI에 대한 선호 URI 참조를 포함하는 Location 헤더 필드를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 자동 리다이렉션을 위해 Location 필드 값을 사용할 수 MAY 있습니다. 서버의 응답 콘텐츠는 보통 새 URI에 대한 짧은 하이퍼텍스트 노트를 포함합니다.

301 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

302 (Found) 상태 코드는 대상 리소스가 임시로 다른 URI에 존재함을 나타냅니다. 리다이렉션이 때때로 변경될 수 있으므로 클라이언트는 향후 요청에 원래 대상 URI를 계속 사용해야 합니다.

서버는 응답에 다른 URI의 URI 참조를 포함하는 Location 헤더 필드를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 자동 리다이렉션을 위해 Location 필드 값을 사용할 수 MAY 있습니다. 서버의 응답 콘텐츠는 보통 다른 URI에 대한 짧은 하이퍼텍스트 노트를 포함합니다.

303 (See Other) 상태 코드는 서버가 사용자 에이전트를 Location 헤더 필드에 있는 다른 리소스로 리다이렉트하고 있음을 나타내며, 이는 원래 요청에 대한 간접 응답을 제공하도록 의도됩니다. 사용자 에이전트는 해당 URI를 대상으로 하는 검색 요청(GET 또는 HEAD)을 수행할 수 있으며, 그 요청도 리다이렉트될 수 있고 최종적으로 얻은 결과를 원래 요청에 대한 응답으로 제시할 수 있습니다. Location 헤더의 새 URI는 대상 URI와 동등하다고 간주되지 않습니다.

이 상태 코드는 모든 HTTP 메서드에 적용될 수 있습니다. 주로 POST 동작의 출력이 사용자 에이전트를 다른 리소스로 리다이렉트하도록 허용하기 위해 사용됩니다. 이렇게 하면 POST 응답에 해당하는 정보를 별도로 식별, 북마크, 캐시할 수 있는 리소스로 제공할 수 있습니다.

GET 요청에 대한 303 응답은 출처 서버가 대상 리소스의 표현을 HTTP로 전송할 수 없음을 의미합니다. 그러나 Location 필드 값은 대상 리소스를 설명하는 리소스를 가리키므로 해당 다른 리소스에 대한 검색 요청이 유용한 표현을 반환할 수 있습니다. 어떤 것이 표현 가능하고 어떤 표현이 적절한지, 무엇이 유용한 설명인지는 HTTP 범위를 벗어납니다.

HEAD 요청에 대한 응답을 제외하고, 303 응답의 표현은 Location 헤더에 제공된 동일한 URI 참조에 대한 하이퍼링크을 포함한 짧은 하이퍼텍스트 노트를 포함하는 것이 바람직합니다.

304 (Not Modified) 상태 코드는 조건부 GET 또는 HEAD 요청이 수신되었고, 조건이 거짓으로 평가되어 200 (OK) 응답이 될 수 있었으나 그럴 필요가 없음을 의미합니다. 즉, 서버는 클라이언트가 이미 유효한 표현을 가지고 있기 때문에 대상 리소스의 표현을 전송할 필요가 없습니다. 서버는 클라이언트가 저장한 표현을 200 (OK) 응답의 내용처럼 사용하도록 안내합니다.

• Content-Location, Date, ETag, 및 Vary
• Cache-Control 및 Expires (캐싱 관련, [CACHING] 참조)

304 응답의 목표는 수신자가 이미 하나 이상의 캐시된 표현을 가지고 있을 때 정보 전송을 최소화하는 것이므로, 발신자는 위에 나열된 필드 이외의 표현 메타데이터를 생성해서는 SHOULD NOT 합니다(단, 캐시 업데이트를 안내하기 위한 메타데이터(예: ETag가 없는 경우의 Last-Modified)는 예외일 수 있습니다).

304 응답을 수신한 캐시의 처리 요구사항은 Section 4.3.4 of [CACHING]에 정의되어 있습니다. 만약 조건부 요청이 외부 클라이언트(예: 자체 캐시를 가진 사용자 에이전트가 공유 프록시에 조건부 GET을 보냄)에서 시작된 경우, 프록시는 그 304 응답을 해당 클라이언트에 전달해야 SHOULD 합니다.

304 응답은 헤더 섹션의 끝에서 종료되며 콘텐츠나 트레일러를 포함할 수 없습니다.

305 (Use Proxy) 상태 코드는 이전 버전의 명세에서 정의되었으며 지금은 더 이상 권장되지 않습니다(참조: Appendix B of [RFC7231]).

306 상태 코드는 이전 버전의 명세에서 정의되었으나 더 이상 사용되지 않으며 코드가 예약되어 있습니다.

307 (Temporary Redirect) 상태 코드는 대상 리소스가 임시로 다른 URI에 있으며, 사용자 에이전트가 자동 리다이렉션을 수행하더라도 요청 메서드를 변경해서는 안 됨을 MUST NOT 나타냅니다. 리다이렉션은 시간이 지남에 따라 변경될 수 있으므로 클라이언트는 향후 요청에 대해 원래 대상 URI를 계속 사용해야 합니다.

서버는 응답에 다른 URI의 URI 참조를 포함하는 Location 헤더 필드를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 자동 리다이렉션을 위해 Location 필드 값을 사용할 수 MAY 있습니다. 서버의 응답 콘텐츠는 보통 다른 URI에 대한 짧은 하이퍼텍스트 노트를 포함합니다.

308 (Permanent Redirect) 상태 코드는 대상 리소스에 새 영구 URI가 할당되었으며 이후 해당 리소스에 대한 모든 참조는 서버가 보낸 새 URI들 중 하나를 사용해야 함을 나타냅니다. 서버는 링크 편집 기능을 가진 사용자 에이전트가 대상 URI에 대한 참조를 새 참조로 영구 교체할 것을 제안할 수 있습니다. 그러나 이 제안은 일반적으로 무시됩니다(사용자가 참조 편집을 실제로 하고 있고 연결이 안전하며 출처 서버가 편집 대상 콘텐츠의 신뢰할 수 있는 권한자일 때를 제외).

서버는 응답에 새 영구 URI에 대한 선호 URI 참조를 포함하는 Location 헤더 필드를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 자동 리다이렉션을 위해 Location 필드 값을 사용할 수 MAY 있습니다. 서버의 응답 콘텐츠는 보통 새 URI에 대한 짧은 하이퍼텍스트 노트를 포함합니다.

308 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

400 (Bad Request) 상태 코드는 요청 구문이 잘못되었거나 요청 메시지 프레이밍이 유효하지 않거나 속이는 요청 라우팅 등 클라이언트 오류로 인식되는 무언가로 인해 서버가 요청을 처리할 수 없음을 나타냅니다.

401 (Unauthorized) 상태 코드는 대상 리소스에 대한 유효한 인증 자격 증명이 부족하여 요청이 적용되지 않았음을 나타냅니다. 401 응답을 생성하는 서버는 해당 대상 리소스에 적용되는 적어도 하나의 챌린지를 포함하는 WWW-Authenticate 헤더 필드를 전송해야 MUST 합니다(Section 11.6.1 참조).

요청에 인증 자격 증명이 포함되어 있었다면 401 응답은 해당 자격 증명에 대한 권한 부여가 거부되었음을 나타냅니다. 사용자 에이전트는 새롭거나 교체된 Authorization 헤더 필드로 요청을 반복할 수 MAY 있습니다. 만약 401 응답이 이전 응답과 동일한 챌린지를 포함하고 있고 사용자 에이전트가 이미 적어도 한 번 인증을 시도했다면, 사용자 에이전트는 보통 진단 정보를 포함하고 있는 표현을 사용자에게 제시해야 SHOULD 합니다.

402 (Payment Required) 상태 코드는 향후 사용을 위해 예약되어 있습니다.

403 (Forbidden) 상태 코드는 서버가 요청을 이해했지만 이행을 거부함을 나타냅니다. 서버가 요청이 금지된 이유를 공개적으로 알리려면 응답 콘텐츠(있다면)에 그 이유를 기술할 수 있습니다.

요청에 인증 자격 증명이 포함되어 있었다면 서버는 이를 충분하지 않다고 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복해서는 SHOULD NOT 하며, 새로운 또는 다른 자격 증명으로 요청을 반복할 수 MAY 있습니다. 그러나 요청이 자격 증명과 무관한 이유로 금지될 수도 있습니다.

출처 서버가 금지된 대상 리소스의 현재 존재를 "숨기고" 싶으면 대신 404 (Not Found) 상태 코드로 응답할 수 MAY 있습니다.

404 (Not Found) 상태 코드는 출처 서버가 대상 리소스에 대한 현재 표현을 찾지 못했거나 존재를 공개하기를 원하지 않음을 나타냅니다. 404는 이 표현의 부재가 일시적인지 영구적인지를 나타내지 않습니다; 영구적이라고 서버가 알고 있다면 410 (Gone)을 404 대신 사용하는 것이 선호됩니다.

404 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

405 (Method Not Allowed) 상태 코드는 요청 라인에 있는 메서드가 출처 서버에서 알려져 있지만 대상 리소스에서 지원되지 않음을 나타냅니다. 출처 서버는 405 응답에서 대상 리소스가 현재 지원하는 메서드 목록을 포함하는 Allow 헤더 필드를 생성해야 MUST 합니다.

405 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

406 (Not Acceptable) 상태 코드는 대상 리소스가 요청에서 수신된 사전적 협상 헤더 필드들에 따라 사용자 에이전트에 허용 가능한 현재 표현을 가지고 있지 않으며, 서버가 기본 표현을 제공할 의사가 없음을 나타냅니다.

서버는 사용자가 가장 적합한 항목을 선택할 수 있도록 사용 가능한 표현 특성 및 해당 리소스 식별자들의 목록을 포함하는 콘텐츠를 생성하는 것이 SHOULD 합니다. 사용자 에이전트는 그 목록에서 자동으로 가장 적절한 선택을 할 수 MAY 있습니다. 다만 이 명세서는 그러한 자동 선택을 위한 표준을 정의하지 않습니다(자세한 내용은 Section 15.4.1 참조).

407 (Proxy Authentication Required) 상태 코드는 401 (Unauthorized)와 유사하지만, 클라이언트가 이 요청을 위해 프록시를 사용하려면 자신을 인증해야 함을 나타냅니다. 프록시는 해당 요청에 적용되는 챌린지를 포함하는 Proxy-Authenticate 헤더 필드를 전송해야 MUST 합니다(Section 11.7.1). 클라이언트는 새롭거나 교체된 Proxy-Authorization 헤더 필드로 요청을 반복할 수 MAY 있습니다(Section 11.7.2 참조).

408 (Request Timeout) 상태 코드는 서버가 기다릴 준비가 된 시간 내에 완전한 요청 메시지를 받지 못했음을 나타냅니다.

클라이언트에 전송 중인 미완료 요청이 있다면 클라이언트는 그 요청을 반복할 수 MAY 있습니다. 현재 연결이 사용 불가능하면(예: HTTP/1.1에서 요청 구분이 손실된 경우) 새 연결을 사용하게 됩니다.

409 (Conflict) 상태 코드는 요청이 대상 리소스의 현재 상태와 충돌하여 완료할 수 없음을 나타냅니다. 사용자가 충돌을 해결하고 요청을 재전송할 수 있는 상황에서 주로 사용됩니다. 서버는 충돌 원인을 사용자가 인식할 수 있도록 충분한 정보를 포함한 콘텐츠를 생성하는 것이 SHOULD 합니다.

충돌은 PUT 요청에 응답할 때 가장 자주 발생합니다. 예를 들어 버전 관리가 사용 중이고 PUT하는 표현이 이전(제3자)의 변경과 충돌하는 경우 출처 서버는 요청을 완료할 수 없음을 나타내기 위해 409 응답을 사용할 수 있습니다. 이 경우 응답 표현에는 수정 이력을 기반으로 차이를 병합하는 데 유용한 정보가 포함될 것입니다.

410 (Gone) 상태 코드는 출처 서버에서 대상 리소스에 대한 접근이 더 이상 가능하지 않으며 이 상태가 영구적일 가능성이 높음을 나타냅니다. 출처 서버가 이 상태가 영구적인지 알 수 없거나 판별 수단이 없다면 대신 404 (Not Found)를 사용해야 합니다.

410 응답은 원격 링크를 제거하도록 알리는 등 웹 유지보수를 돕기 위해 주로 사용됩니다. 이는 기간 한정 프로모션 서비스나 출처 서버 사이트와 더 이상 관련이 없는 개인의 리소스 등에 흔히 발생합니다. 모든 영구적으로 사용 불가능한 리소스를 반드시 "gone"으로 표시하거나 일정 기간 보관할 필요는 없습니다 — 이는 서버 소유자의 재량입니다.

410 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

411 (Length Required) 상태 코드는 서버가 Content-Length를 정의하지 않은 요청을 수락하지 않음을 나타냅니다(Section 8.6). 클라이언트는 요청 본문의 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가하여 요청을 반복할 수 MAY 합니다.

412 (Precondition Failed) 상태 코드는 요청 헤더 필드에 주어진 하나 이상의 조건이 서버에서 검사되었을 때 거짓으로 평가되었음을 나타냅니다(Section 13). 이 응답 상태 코드는 클라이언트가 현재 리소스 상태(현재 표현 및 메타데이터)에 선행 조건을 부과하여 대상 리소스가 예상 상태에 있지 않으면 요청 메서드가 적용되는 것을 방지할 수 있게 합니다.

413 (Content Too Large) 상태 코드는 요청 콘텐츠가 서버가 처리하려는 한계보다 커서 서버가 요청을 처리하지 않겠음을 나타냅니다. 서버는 프로토콜 버전이 허용하면 요청을 종료할 수 MAY 있으며, 그렇지 않으면 연결을 닫을 수 MAY 있습니다.

조건이 일시적이라면 서버는 클라이언트가 다시 시도할 수 있는 시점을 나타내는 Retry-After 헤더 필드를 생성하는 것이 SHOULD 합니다.

414 (URI Too Long) 상태 코드는 대상 URI가 서버가 해석하려는 허용 길이보다 길어 요청을 서비스할 수 없음을 나타냅니다. 이 드문 조건은 클라이언트가 POST 요청을 GET으로 잘못 변환하여 긴 쿼리 정보를 포함시켰거나, 클라이언트가 리다이렉션 무한 루프에 빠졌거나, 공격자가 보안 취약점을 악용하려는 경우에 발생할 수 있습니다.

414 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

415 (Unsupported Media Type) 상태 코드는 출처 서버가 이 메서드에 대해 대상 리소스에서 요청의 콘텐츠 형식을 지원하지 않기 때문에 요청을 처리하지 않음을 나타냅니다.

형식 문제는 요청의 지정된 Content-Type 또는 Content-Encoding 때문일 수 있으며, 데이터 자체를 검사한 결과일 수도 있습니다.

문제가 지원되지 않는 콘텐츠 코딩 때문이라면, 응답의 Accept-Encoding 헤더 필드(Section 12.5.3)를 사용하여 요청에서 수용되었을 가능성이 있는 콘텐츠 코딩을 나타내는 것이 바람직합니다.

반면 문제가 지원되지 않는 미디어 타입 때문이라면, 응답의 Accept 헤더 필드(Section 12.5.1)를 사용하여 요청에서 수용되었을 미디어 타입을 나타낼 수 있습니다.

416 (Range Not Satisfiable) 상태 코드는 요청의 Range 헤더에 포함된 범위 집합이 거부되었음을 나타냅니다. 이는 요청된 범위 중 어느 것도 만족 불가능하거나, 클라이언트가 과도한 수의 작은 또는 겹치는 범위를 요청했을 때(잠재적 서비스 거부 공격) 발생할 수 있습니다.

각 범위 단위는 자체 범위 집합이 만족 가능한지에 필요한 요건을 정의합니다. 예를 들어 Section 14.1.2는 bytes 범위 집합이 만족 가능한 조건을 정의합니다.

바이트 범위 요청에 대해 416 응답을 생성하는 서버는 선택된 표현의 현재 길이를 지정하는 Content-Range 헤더 필드를 생성하는 것이 SHOULD 합니다(Section 14.4 참조).

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

417 (Expectation Failed) 상태 코드는 요청의 Expect 헤더 필드(Section 10.1.1)에 주어진 기대 중 적어도 하나가 들어오는 서버들 중 하나 이상에서 충족될 수 없음을 나타냅니다.

[RFC2324]는 HTTP의 남용을 풍자한 4월 1일자 RFC였으며; 그 중 하나의 남용은 애플리케이션 특정 418 상태 코드의 정의였고, 이는 농담으로 배포되어 충분히 널리 퍼져 향후 사용을 위한 코드로 사용할 수 없게 되었습니다.

따라서 418 상태 코드는 IANA HTTP 상태 코드 레지스트리에 예약되어 있습니다. 이는 현재 그 상태 코드가 다른 애플리케이션에 할당될 수 없음을 의미합니다. 향후 상황이 요구되면(예: 4NN 상태 코드 고갈) 재할당될 수 있습니다.

421 (Misdirected Request) 상태 코드는 요청이 대상 URI에 대한 권한 있는 응답을 생성할 수 없거나 생성하기를 원치 않는 서버로 향해졌음을 나타냅니다. 출처 서버(또는 출처 서버를 대신하는 게이트웨이)는 서버가 구성된 origin과 일치하지 않거나 요청을 수신한 연결 컨텍스트와 일치하지 않는 대상 URI를 거부하기 위해 421을 보냅니다(Section 4.3.1, Section 7.4 참조).

421 응답을 수신한 클라이언트는 요청 메서드가 멱등인지 여부에 관계없이 다른 연결(예: 대상 리소스의 origin에 특정한 새 연결)이나 대체 서비스([ALTSVC])를 통해 요청을 재시도할 수 MAY 있습니다.

프록시는 421 응답을 생성해서는 MUST NOT 합니다.

422 (Unprocessable Content) 상태 코드는 서버가 요청 콘텐츠의 미디어 타입을 이해하고(따라서 415 (Unsupported Media Type)는 부적절함), 요청 콘텐츠의 문법이 올바르지만 포함된 지시사항을 처리할 수 없었음을 나타냅니다. 예를 들어 XML 요청 콘텐츠가 잘 구성되어(문법적으로 올바르지만) 의미상 오류가 있는 XML 지시사항을 포함하는 경우 이 상태 코드를 보낼 수 있습니다.

426 (Upgrade Required) 상태 코드는 서버가 현재 프로토콜을 사용하여 요청을 수행하기를 거부하지만, 클라이언트가 다른 프로토콜로 업그레이드하면 수행할 의향이 있음을 나타냅니다. 426 응답을 생성하는 서버는 요구되는 프로토콜을 나타내는 Upgrade 헤더 필드를 전송해야 MUST 합니다(Section 7.8 참조).

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

500 (Internal Server Error) 상태 코드는 서버가 요청을 이행하는 동안 예기치 않은 조건이 발생했음을 나타냅니다.

501 (Not Implemented) 상태 코드는 서버가 요청을 이행하는 데 필요한 기능을 지원하지 않음을 나타냅니다. 서버가 요청 메서드를 인식하지 못하고 어떤 리소스에 대해서도 지원할 수 없을 때 적절한 응답입니다.

501 응답은 휴리스틱하게 캐시 가능하며, 즉 메서드 정의나 명시적 캐시 제어에 달리 표시되지 않는 한 캐시될 수 있습니다(자세한 내용은 Section 4.2.2 of [CACHING] 참조).

502 (Bad Gateway) 상태 코드는 서버가 게이트웨이 또는 프록시로 동작하는 동안 요청을 이행하려고 액세스한 인바운드 서버로부터 무효한 응답을 수신했음을 나타냅니다.

503 (Service Unavailable) 상태 코드는 서버가 일시적 과부하 또는 예정된 정비로 인해 현재 요청을 처리할 수 없음을 나타냅니다. 이 상태는 일정 시간 후에 완화될 가능성이 높습니다. 서버는 클라이언트가 재시도할 적절한 시간을 제안하기 위해 Retry-After 헤더 필드를 전송할 수 MAY 있습니다(Section 10.2.3 참조).

504 (Gateway Timeout) 상태 코드는 서버가 게이트웨이 또는 프록시로 동작하는 동안 요청을 완료하기 위해 필요한 상위 서버로부터 적시 응답을 받지 못했음을 나타냅니다.

505 (HTTP Version Not Supported) 상태 코드는 서버가 요청 메시지에서 사용된 HTTP의 주(major) 버전을 지원하지 않거나 지원을 거부함을 나타냅니다. 서버는 클라이언트와 동일한 주(major) 버전으로 요청을 완료할 수 없음을 나타내며, 해당 버전을 지원하지 않는 이유 및 서버가 지원하는 다른 프로토콜을 설명하는 표현을 생성하는 것이 SHOULD 합니다.

"Hypertext Transfer Protocol (HTTP) Method Registry"는 IANA가 https://www.iana.org/assignments/http-methods에서 관리하며, 메서드 이름들을 등록합니다.

• 메서드 이름(참조: Section 9)
• 안전 여부("yes" 또는 "no", 참조: Section 9.2.1)
• 멱등성 여부("yes" 또는 "no", 참조: Section 9.2.2)
• 명세 텍스트에 대한 포인터

이 네임스페이스에 값을 추가하려면 IETF 검토가 필요합니다(참조: [RFC8126], Section 4.8).

표준화된 메서드는 일반적입니다; 즉 특정 미디어 타입이나 특정 종류의 리소스, 애플리케이션에만 적용되는 것이 아니라 잠재적으로 모든 리소스에 적용될 수 있습니다. 따라서 새로운 메서드는 특정 애플리케이션이나 데이터 형식에 국한되지 않는 문서에 등록하는 것이 바람직합니다. 직교적인 기술은 직교적인 명세를 가질 자격이 있습니다.

메시지 구문 분석(Section 6)은 메서드 의미론과 독립적이어야 하므로(HEAD에 대한 응답을 제외), 새로운 메서드의 정의는 구문 분석 알고리즘을 변경하거나 요청 또는 응답 메시지에 콘텐츠의 존재를 금지할 수 없습니다. 새로운 메서드 정의는 Content-Length 헤더 필드 값을 "0"으로 요구하여 오직 0길이 콘텐츠만 허용한다고 명시할 수 있습니다.

마찬가지로, 새로운 메서드는 CONNECT(CONNECT)와 OPTIONS(OPTIONS)에 허용되는 호스트:포트 및 별표 형태의 요청 대상과 같은 특수한 요청 대상 형식을 사용할 수 없습니다(Section 7.1). 대상 URI에 대해 전체 URI(절대 형식)가 필요하므로 요청 대상은 절대형으로 전송되거나 다른 메서드와 동일한 방식으로 요청 컨텍스트에서 대상 URI가 재구성되어야 합니다.

새 메서드 정의는 그것이 안전한지(Section 9.2.1), 멱등인지(Section 9.2.2), 캐시 가능인지(Section 9.2.3), 요청 콘텐츠(있다면)에 어떤 의미론이 연관되는지, 그리고 헤더 필드나 상태 코드 의미론에 어떤 정제가 필요한지를 명시해야 합니다. 새로운 메서드가 캐시 가능하다면, 캐시가 언제 어떻게 응답을 저장하고 이후 요청을 만족시키는 데 사용할 수 있는지 설명해야 합니다. 또한 새로운 메서드가 조건부로 만들 수 있는지(Section 13.1) 여부와, 그렇다면 조건이 거짓일 때 서버가 어떻게 응답하는지 설명해야 합니다. 마찬가지로, 새로운 메서드가 부분 응답 의미론(Section 14.2)에 어떤 용도가 있을 수 있다면, 그것도 문서화해야 합니다.

"Hypertext Transfer Protocol (HTTP) Status Code Registry"는 IANA가 https://www.iana.org/assignments/http-status-codes에서 관리하며, 상태 코드 번호를 등록합니다.

• 상태 코드(3자리)
• 짧은 설명
• 명세 텍스트에 대한 포인터

이 HTTP 상태 코드 네임스페이스에 값을 추가하려면 IETF 검토가 필요합니다(참조: [RFC8126], Section 4.8).

현재 상태 코드로 정의되지 않은 응답 의미론을 표현해야 할 필요가 있을 때 새 상태 코드를 등록할 수 있습니다. 상태 코드는 일반적이며, 특정 미디어 타입이나 리소스 종류, HTTP의 특정 응용에만 적용되는 것이 아닙니다. 따라서 새 상태 코드는 특정 응용에 한정되지 않는 문서에 등록하는 것이 바람직합니다.

새 상태 코드는 Section 15에 정의된 분류 중 하나에 속해야 합니다. 기존 파서가 응답 메시지를 처리할 수 있도록 새 상태 코드는 콘텐츠를 금지할 수 없지만 0-길이 콘텐츠를 요구할 수는 있습니다.

아직 널리 배포되지 않은 새 상태 코드 제안은 코드 번호를 조기에 할당하지 않도록 권고됩니다. 명확한 합의가 있을 때까지 특정 번호 대신 "4NN" 또는 "3N0" .. "3N9" 같은 표기를 사용하여 제안된 상태 코드의 클래스만 표시하는 것이 바람직합니다.

새 상태 코드의 정의에는 해당 상태 코드를 포함하는 응답을 유발할 요청 조건(예: 요청 헤더 필드 및/또는 메서드 조합)과 응답 헤더 필드에 대한 종속성(필드가 필수인지, 어떤 필드가 의미를 변경하는지, 새 상태 코드와 함께 사용될 때 어떤 필드 의미가 정제되는지)을 설명해야 합니다.

기본적으로 상태 코드는 그것이 발생한 응답에 해당하는 요청에만 적용됩니다. 상태 코드가 더 넓은 적용 범위(예: 해당 리소스에 대한 모든 요청 또는 서버에 대한 모든 요청)에 적용된다면 이는 명시적으로 지정되어야 합니다. 이렇게 할 때 모든 클라이언트가 새 상태 코드를 이해하지 못할 수 있으므로 일관되게 더 넓은 범위를 적용할 것을 기대할 수 없다는 점을 명시해야 합니다.

새 최종 상태 코드의 정의는 그것이 휴리스틱하게 캐시할 수 있는지 여부를 지정해야 합니다. 모든 최종 상태 코드 응답은 명시적 신선도 정보가 있으면 캐시될 수 있다는 점에 유의하십시오. 상태 코드가 휴리스틱 캐시 가능하도록 정의되면 명시적 신선도 정보 없이도 캐시될 수 있습니다. 마찬가지로 상태 코드의 정의는 must-understand 캐시 지시자가 사용될 경우 캐시 동작에 제약을 둘 수 있습니다. 자세한 내용은 [CACHING]를 참조하십시오.

마지막으로, 새 상태 코드 정의는 그 콘텐츠가 식별된 리소스와 어떤 암묵적 연관을 가지는지(Section 6.4.2)를 표시해야 합니다.

"Hypertext Transfer Protocol (HTTP) Field Name Registry"는 HTTP 필드 이름의 네임스페이스를 정의합니다.

누구나 HTTP 필드 등록을 요청할 수 있습니다. 새 HTTP 필드를 만들 때 고려할 사항은 Section 16.3.2을 참조하십시오.

"Hypertext Transfer Protocol (HTTP) Field Name Registry"는 https://www.iana.org/assignments/http-fields/에 있습니다. 등록 요청은 그곳의 지침을 따르거나 "ietf-http-wg@w3.org" 메일링 리스트로 이메일을 보내 요청할 수 있습니다.

필드 이름은 지정된 전문가(IESG 또는 위임자가 임명)가 조언을 바탕으로 등록합니다. 상태가 'permanent'인 필드는 Specification Required입니다(참조: [RFC8126], Section 4.6).

Field name:

요청된 필드 이름. Section 5.1에 정의된 field-name 문법을 준수해야 MUST 하며, 문자, 숫자 및 하이픈('-') 문자만으로 제한하는 것이 바람직하며 첫 문자는 문자여야 SHOULD 합니다.

Status:

"permanent", "provisional", "deprecated", 또는 "obsoleted".

Specification document(s):

필드를 규정하는 문서에 대한 참조, 바람직하게는 문서를 검색할 수 있는 URI를 포함. 임시 등록의 경우 선택적이지만 권장됩니다. 관련 섹션을 표시할 수 있으나 필수는 아닙니다.

Comments:

예약된 항목 등에 대한 추가 정보.

전문가(들)는 커뮤니티와 협의하여 레지스트리에 수집할 추가 필드를 정의할 수 있습니다.

표준으로 정의된 이름은 상태가 "permanent"입니다. 전문가(들)가 사용 중이며 적절히 커뮤니티와 협의한 경우 다른 이름도 permanent로 등록할 수 있습니다. 그렇지 않은 이름은 "provisional"로 등록되어야 합니다.

전문가(들)는 커뮤니티와 협의하여 임시 항목이 사용되지 않는다고 판단하면 이를 제거할 수 있습니다. 전문가(들)는 언제든 임시 항목의 상태를 permanent로 변경할 수 있습니다.

전문가(들)는 등록되지 않은 이름이 널리 배포되어 있고 그렇지 않으면 시기적절하게 등록되지 않을 가능성이 높다고 판단하면 제3자(전문가 포함)가 이름을 등록할 수 있도록 허용할 수 있습니다.

HTTP 헤더 및 트레일러 필드는 프로토콜의 널리 사용되는 확장 포인트입니다. 임의로 사용될 수는 있으나, 광범위한 사용을 의도한 필드는 상호운용성을 보장하기 위해 신중하게 문서화되어야 합니다.

• 어떤 조건에서 필드를 사용할 수 있는지; 예: 응답에서만, 요청 또는 응답 모두에서, 특정 요청 메서드에 대한 응답에서만 등.
• 필드 의미가 특정 요청 메서드나 상태 코드와 같이 문맥에 의해 추가로 정제되는지 여부.
• 전달되는 정보의 적용 범위. 기본적으로 필드는 연관된 메시지에만 적용되지만, 일부 응답 필드는 리소스의 모든 표현이나 리소스 자체, 또는 더 넓은 범위에 적용되도록 설계될 수 있습니다. 응답 필드의 범위를 확장하는 명세는 콘텐츠 협상, 적용 기간, 다중 테넌트 서버 배포와 같은 문제를 신중히 고려해야 합니다.
• 중개자가 필드 값을 삽입, 삭제 또는 수정할 수 있는 조건.
• 필드가 트레일러에서 허용되는지 여부; 기본적으로 그렇지 않습니다(참조: Section 6.5.1).
• 필드가 홉-바이-홉인지(즉 Connection 헤더에 필드 이름을 나열해야 하는지) 여부(참조: Connection, Section 7.6.1).
• 프라이버시 관련 데이터 노출과 같은 추가 보안 고려사항이 있는지 여부.

• 해당 필드 이름을 응답의 Vary 헤더 필드에 나열하는 것이 적절한지(예: 요청 헤더 필드가 출처 서버의 콘텐츠 선택 알고리즘에 사용되는 경우; 참조: Section 12.5.5).
• 필드가 PUT 요청에서 수신될 때 저장될 의도인지 여부(참조: Section 9.3.4).
• 보안상의 우려로 인해 자동 리다이렉션 시 필드를 제거해야 하는지 여부(참조: Section 15.4).

"Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"는 챌린지와 자격 증명에서 사용되는 인증 스킴 네임스페이스를 정의하며 https://www.iana.org/assignments/http-authschemes에서 관리됩니다.

• 인증 스킴 이름
• 명세 텍스트에 대한 포인터
• 메모(선택)

이 네임스페이스에 값을 추가하려면 IETF 검토가 필요합니다(참조: [RFC8126], Section 4.8).

• HTTP 인증은 상태 비저장(stateless)으로 가정됩니다: 요청을 인증하는 데 필요한 모든 정보는 요청 내에 제공되어야 MUST 하며, 서버가 이전 요청을 기억하는 것에 의존해서는 안 됩니다. 기저 연결에 바인딩되거나 그에 기반한 인증은 이 명세서의 범위를 벗어나며, 그 연결이 인증된 사용자 외의 어떤 당사자도 사용할 수 없도록 보장하는 조치가 취해지지 않는 한 본질적으로 결함이 있습니다(참조: Section 3.3).

• 인증 매개변수 "realm"은 보호 영역을 정의하는 데 예약되어 있으므로(Section 11.5) 새 스킴은 그 정의와 호환되지 않게 "realm"을 사용해서는 MUST NOT 합니다.

• "token68" 표기법은 기존 인증 스킴과의 호환을 위해 도입되었고 챌린지나 자격 증명에서 한 번만 사용할 수 있습니다. 따라서 새 스킴은 향후 확장이 불가능해지지 않도록 auth-param 구문을 사용하는 것이 바람직합니다.

• 챌린지와 자격 증명의 구문 분석은 이 명세서에 의해 정의되며 새 인증 스킴이 이를 수정할 수 없습니다. auth-param 구문을 사용할 때 모든 매개변수는 token 및 quoted-string 문법을 모두 지원해야 하며(즉, quoted-string 처리가 필요), 구문 분석 후 필드 값에 대한 문법적 제약이 정의되어야 합니다. 이는 수신자가 모든 인증 스킴에 적용되는 일반 파서를 사용할 수 있도록 하기 위해 필요합니다.

  참고: "realm" 매개변수의 값 문법이 quoted-string으로 제한된 것은 반복하지 말아야 할 잘못된 설계 선택이었습니다.

• 새 스킴 정의는 알려지지 않은 확장 매개변수 처리 방법을 정의해야 합니다. 일반적으로 "must-ignore" 규칙이 "must-understand" 규칙보다 바람직합니다. 그렇지 않으면 레거시 수신자가 존재하는 환경에서 새 매개변수를 도입하기 어렵습니다. 또한 새 매개변수를 정의하는 정책(예: "명세를 갱신" 또는 "이 레지스트리 사용")을 설명하는 것이 좋습니다.

• 인증 스킴 정의는 해당 스킴이 원본 서버 인증(즉 WWW-Authenticate 사용)과/또는 프록시 인증(즉 Proxy-Authenticate 사용)에 사용할 수 있는지 여부를 문서화해야 합니다.

• Authorization 헤더에 담긴 자격 증명은 사용자 에이전트에 특화되어 있으므로, 그것들이 나타나는 요청 범위 내에서 HTTP 캐시에 대해 "private" 캐시 응답 지시자와 동일한 효과를 가집니다(참조: Section 5.2.2.7 of [CACHING]).

  따라서 Authorization 헤더에 자격 증명을 담지 않는 새 인증 스킴(예: 새로 정의된 헤더 사용)은 캐싱을 명시적으로 금지해야 하며(예: "private" 사용을 의무화), 이를 명세에 명시해야 합니다.

• Authentication-Info, Proxy-Authentication-Info 또는 기타 인증 관련 응답 헤더 필드를 사용하는 스킴은 관련 보안 고려사항을 문서화해야 합니다(참조: Section 17.16.4).

"HTTP Range Unit Registry"는 범위 단위 이름의 네임스페이스를 정의하고 해당 사양을 참조합니다. 이는 https://www.iana.org/assignments/http-parameters에서 관리됩니다.

• 이름
• 설명
• 명세 텍스트에 대한 포인터

이 네임스페이스에 값을 추가하려면 IETF 검토가 필요합니다(참조: [RFC8126], Section 4.8).

페이지, 섹션, 레코드, 행 또는 시간 같은 형식 특정 경계와 같은 다른 범위 단위는 애플리케이션 특정 목적을 위해 HTTP에서 사용할 수 있으나 실제로 널리 사용되지는 않습니다. 대체 범위 단위를 구현하는 사람들은 그것들이 콘텐츠 코딩 및 범용 중개자와 어떻게 동작할지 고려해야 합니다.

"HTTP Content Coding Registry"는 IANA가 https://www.iana.org/assignments/http-parameters/에서 관리하며 content-coding 이름을 등록합니다.

• 이름
• 설명
• 명세 텍스트에 대한 포인터

콘텐츠 코딩의 이름은 전송 코딩 이름과 중복되어서는 MUST NOT 하며(동일한 인코딩 변환일 경우를 제외, 예: 섹션 8.4.1의 압축 코딩들), "HTTP Transfer Coding Registry"(https://www.iana.org/assignments/http-parameters/)와 겹치지 않아야 합니다.

이 네임스페이스에 값을 추가하려면 IETF 검토가 필요하며(참조: [RFC8126], Section 4.8) 콘텐츠 코딩의 목적(참조: Section 8.4.1)을 준수해야 MUST 합니다.

새 콘텐츠 코딩은 가능한 한 자체 설명적이어야 하며, 선택적 매개변수는 전송 중에 손실될 수 있는 외부 메타데이터에 의존하지 말고 코딩 형식 자체 내에서 발견 가능하도록 하는 것이 바람직합니다.

HTTP 인증 프레임워크는 자격 증명의 기밀성을 유지하기 위한 단일 메커니즘을 정의하지 않습니다; 대신 각 인증 스킴은 전송 전에 자격 증명이 어떻게 인코딩되는지를 정의합니다. 이는 향후 인증 스킴 개발에 유연성을 제공하지만, 자체적으로 기밀성을 제공하지 않거나 재사용(replay) 공격에 충분히 대응하지 못하는 기존 스킴을 보호하기에는 불충분할 수 있습니다. 또한 서버가 사용자별 자격 증명을 기대하는 경우에는 자격 증명의 내용이 기밀로 유지되더라도 해당 교환은 사용자를 식별하는 효과를 가집니다.

HTTP는 필드의 기밀 전송을 제공하기 위해 기저 전송 또는 세션 수준 연결의 보안 특성에 의존합니다. 개별 사용자 인증에 의존하는 서비스는 자격 증명을 교환하기 전에 보호된 연결을 요구합니다(Section 4.2.2).

기존 HTTP 클라이언트와 사용자 에이전트는 일반적으로 인증 정보를 무기한 보유하는 경향이 있습니다. HTTP는 출처 서버가 클라이언트에게 이러한 캐시된 자격 증명을 폐기하도록 지시할 수 있는 메커니즘을 제공하지 않습니다. 이는 프로토콜이 자격 증명이 어떻게 획득되거나 사용자 에이전트에 의해 어떻게 관리되는지 알지 못하기 때문입니다. 자격 증명의 만료 또는 철회 메커니즘은 인증 스킴 정의의 일부로 명시될 수 있습니다.

• 장기간 유휴 상태였던 클라이언트가 이후 서버가 사용자에게 자격 증명을 다시 입력하도록 유도하고자 하는 경우.
• 애플리케이션이 세션 종료 표시(예: 페이지의 "로그아웃" 또는 "커밋" 버튼)를 포함하는 경우, 그 이후 서버 측 애플리케이션은 클라이언트가 자격 증명을 보관할 더 이상의 이유가 없음을 "알게" 됩니다.

자격 증명을 캐시하는 사용자 에이전트는 사용자 제어 하에 캐시된 자격 증명을 쉽게 폐기할 수 있는 메커니즘을 제공하는 것이 권장됩니다.

"realm" 메커니즘에만 의존해 보호 영역을 설정하는 인증 스킴은 동일한 출처(origin) 서버의 모든 리소스에 자격 증명을 노출하게 됩니다. 리소스에 대해 성공적으로 인증 요청을 수행한 클라이언트는 동일한 출처 서버의 다른 리소스에 동일한 인증 자격 증명을 사용할 수 있습니다. 이로 인해 다른 리소스가 다른 리소스의 인증 자격 증명을 수집할 수 있는 가능성이 생깁니다.

이는 특히 출처 서버가 동일한 origin 아래에서 여러 당사자를 호스팅할 때 문제가 됩니다(참조: Section 11.5). 가능한 완화 전략에는 인증 자격 증명에 대한 직접 접근을 제한(예: Authorization 요청 헤더 필드의 내용 제공을 막음)하거나 각 당사자에 대해 서로 다른 호스트 이름(또는 포트 번호)을 사용하여 보호 영역을 분리하는 것이 포함됩니다.

암호화되지 않은 채널을 통해 전송되는 응답에 정보를 추가하는 것은 보안과 프라이버시에 영향을 미칠 수 있습니다. Authentication-Info 및 Proxy-Authentication-Info 헤더 필드의 존재만으로도 HTTP 인증이 사용 중임을 나타냅니다. 인증 스킴별 매개변수의 내용이 추가 정보를 노출할 수 있으므로 이는 해당 스킴 정의에서 고려되어야 합니다.