HTTP 의미론

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

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

"http" URI의 오리진 서버는 호스트 식별자([URI], 3.2.2절)와 선택적 포트 번호([URI], 3.2.3절)를 포함하는 authority 구성요소로 식별됩니다. port 하위 구성요소가 비어 있거나 지정되지 않으면 TCP 포트 80 (WWW 서비스용 예약 포트)이 기본값입니다. 오리진은 식별된 리소스를 대상으로 하는 요청에 권위 있게 응답할 권한이 누구에게 있는지를 4.3.2절에 정의된 대로 결정합니다.

송신자는 빈 host 식별자가 있는 "http" URI를 MUST NOT 생성해야 합니다. 그러한 URI 참조를 처리하는 수신자는 이를 유효하지 않은 것으로 MUST 거부해야 합니다.

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

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

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

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

송신자는 빈 host 식별자가 있는 "https" URI를 MUST NOT 생성해야 합니다. 그러한 URI 참조를 처리하는 수신자는 이를 유효하지 않은 것으로 MUST 거부해야 합니다.

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

클라이언트는 "https" 리소스에 대한 HTTP 요청이 전달되기 전에 보호되도록 하고, 해당 요청에 대한 보호된 응답만 수락하도록 MUST 해야 합니다. 클라이언트와 서버가 허용할 수 있는 암호화 메커니즘의 정의는 일반적으로 협상되며 시간이 지나면서 변경될 수 있습니다.

"https" 스킴을 통해 제공되는 리소스는 "http" 스킴과 공유되는 식별성을 갖지 않습니다. 이들은 별도의 네임스페이스를 가진 서로 다른 오리진입니다. 그러나 Cookie 프로토콜 [COOKIE]처럼 동일한 host를 가진 모든 오리진에 적용되는 것으로 정의된 HTTP 확장은 한 서비스가 설정한 정보가 일치하는 host 도메인 그룹 내의 다른 서비스와의 통신에 영향을 미칠 수 있도록 합니다. 이러한 확장은 보호된 연결에서 얻은 정보가 보호되지 않은 컨텍스트에서 의도치 않게 교환되는 것을 방지하도록 매우 신중하게 설계해야 합니다.

"http" 또는 "https" 스킴이 있는 URI는 각 스킴에 대해 위에서 설명한 기본값을 사용하여 [URI]의 6절에 정의된 방법에 따라 정규화되고 비교됩니다.

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

• 포트가 스킴의 기본 포트와 같으면 정규 형식에서는 port 하위 구성요소를 생략합니다.
• OPTIONS 요청의 대상으로 사용되지 않는 경우 빈 path 구성요소는 "/"의 절대 경로와 동등하므로 정규 형식에서는 대신 "/" 경로를 제공합니다.
• scheme과 host는 대소문자를 구분하지 않으며 일반적으로 소문자로 제공됩니다. 다른 모든 구성요소는 대소문자를 구분하여 비교됩니다.
• "reserved" 집합에 속하지 않는 문자는 해당 퍼센트 인코딩된 옥텟과 동등합니다. 정규 형식에서는 이를 인코딩하지 않습니다(2.1절 및 2.2절의 [URI] 참조).

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

정규화 후(어떤 방법을 사용하든) 동등한 두 HTTP URI는 동일한 리소스를 식별한다고 가정할 수 있으며, 모든 HTTP 구성요소가 정규화를 MAY 수행할 수 있습니다. 따라서 서로 다른 리소스는 정규화 후([URI]의 6.2절에 정의된 방법 중 하나를 사용하여) 동등한 HTTP URI로 식별하는 것을 SHOULD NOT 해야 합니다.

authority의 URI 일반 구문에는 URI에 사용자 인증 정보를 포함하기 위한 userinfo 하위 구성요소([URI], 3.2.1절)도 포함됩니다. 해당 하위 구성요소에서 "user:password" 형식의 사용은 폐기되었습니다.

일부 구현은 명령 호출 옵션, 구성 파일 또는 북마크 목록 등에서 인증 정보의 내부 구성을 위해 userinfo 구성요소를 사용하며, 이러한 사용은 사용자 식별자 또는 암호를 노출할 수 있습니다.

송신자는 "http" 또는 "https" URI 참조가 메시지 내에서 대상 URI 또는 필드 값으로 생성될 때 userinfo 하위 구성요소(및 그 "@" 구분자)를 MUST NOT 생성해야 합니다.

신뢰할 수 없는 소스에서 받은 "http" 또는 "https" URI 참조를 사용하기 전에 수신자는 userinfo를 구문 분석하고 그 존재를 오류로 취급하는 것이 SHOULD 요구됩니다. 이는 피싱 공격을 위해 authority를 숨기는 데 사용되고 있을 가능성이 높습니다.

프래그먼트 식별자는 [URI]의 3.5절에 정의된 대로 URI 스킴과 독립적으로 보조 리소스를 간접적으로 식별할 수 있도록 합니다. URI를 참조하는 일부 프로토콜 요소는 프래그먼트를 포함할 수 있지만 다른 요소는 그렇지 않습니다. 프래그먼트가 허용되는 요소에는 ABNF 규칙을 사용하여 이를 구분하고, 그렇지 않은 경우 프래그먼트를 제외하는 특정 규칙을 사용합니다.

주어진 URI의 오리진은 scheme과 host를 소문자로 정규화하고 port의 선행 0을 제거하도록 정규화한 후의 scheme, host 및 port의 세 값입니다. URI에서 port가 생략된 경우 해당 스킴의 기본 포트를 사용합니다. 예를 들어 URI

   https://Example.Com/happy.js

의 오리진은 다음과 같습니다.

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

   https://example.com:443

각 오리진은 자체 네임스페이스를 정의하고 해당 네임스페이스의 식별자가 리소스에 매핑되는 방식을 제어합니다. 다시 말해 오리진이 유효한 요청에 시간에 걸쳐 일관되게 응답하는 방식이 사용자가 URI와 연결할 의미론을 결정하며, 이러한 의미론의 유용성이 궁극적으로 이러한 메커니즘을 사용자가 향후 참조하고 접근할 수 있는 리소스로 변환합니다.

두 오리진은 scheme, host 또는 port가 다르면 서로 다릅니다. 동일한 엔터티가 서로 다른 두 오리진을 제어하는 것으로 확인되더라도, 해당 오리진 아래의 두 네임스페이스는 해당 오리진에 대한 권한 있는 서버가 명시적으로 별칭을 지정하지 않는 한 서로 다릅니다.

Origin은 이 문서의 범위를 넘어 HTML 및 관련 웹 프로토콜에서도 사용되며, [RFC6454]에 설명되어 있습니다.

HTTP는 전송 프로토콜과 독립적이지만 "http" 스킴(4.2.1절)은 authority 구성요소에서 식별된 host의 지정된 포트에서 TCP 연결을 수신 대기하는 오리진 서버를 제어하는 주체와 authority를 연결하는 데 특화되어 있습니다. 이는 클라이언트별 이름 확인 메커니즘과 경로상 공격자로부터 보호되지 않을 수 있는 통신 모두에 의존하므로 매우 약한 의미의 authority입니다. 그럼에도 신뢰할 수 있는 환경에서 일관되게 확인하기 위해 "http" 식별자를 오리진 서버에 바인딩하는 데 충분한 최소 수준입니다.

host 식별자가 IP 주소로 제공된 경우 오리진 서버는 해당 IP 주소에서 지정된 TCP 포트의 수신기(있는 경우)입니다. host가 등록된 이름인 경우 등록된 이름은 DNS와 같은 이름 확인 서비스에서 적절한 오리진 서버의 주소를 찾는 데 사용되는 간접 식별자입니다.

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

서버가 그러한 요청에 15절에 설명된 비임시 HTTP 응답 메시지로 응답하면 해당 응답은 클라이언트의 요청에 대한 권위 있는 응답으로 간주됩니다.

그러나 위 방법이 권위 있는 응답을 얻는 유일한 수단은 아니며, 권위 있는 응답이 항상 필요하다는 의미도 아닙니다([CACHING] 참조). 예를 들어 Alt-Svc 헤더 필드 [ALTSVC]를 사용하면 오리진 서버가 해당 오리진에 대해서도 권위 있는 다른 서비스를 식별할 수 있습니다. "http"로 식별된 리소스에 대한 접근은 이 문서의 범위 밖에 있는 프로토콜에서도 제공할 수 있습니다.

"https" 스킴(4.2.2절)은 클라이언트가 식별된 오리진 서버에 대해 신뢰할 수 있다고 판단하는 인증서에 대응하는 개인 키를 서버가 사용할 수 있는 능력을 기반으로 authority를 연결합니다. 클라이언트는 일반적으로 사전 설정되거나 구성된 신뢰 앵커에서 전달되는 신뢰 체인을 바탕으로 인증서를 신뢰할 수 있다고 판단합니다(4.3.4절).

HTTP/1.1 이하에서 클라이언트는 해당 URI 오리진의 host에 명시적으로 연결된, 성공적으로 설정되고 보호된 연결을 통해 통신하는 경우에만 서버에 authority를 부여합니다. 연결 설정과 인증서 검증은 authority의 증거로 사용됩니다.

HTTP/2와 HTTP/3에서 클라이언트는 URI 오리진의 host가 서버 인증서에 있는 host 중 하나와 일치하고 클라이언트가 해당 URI에 대해 그 host로 연결을 열 수 있다고 판단하는 경우, 성공적으로 설정되고 보호된 연결을 통해 통신 중인 서버에 authority를 부여합니다. 실제로 클라이언트는 오리진의 host가 설정된 연결과 동일한 서버 IP 주소를 포함하는지 확인하기 위해 DNS 질의를 수행합니다. 이 제한은 오리진 서버가 동등한 ORIGIN 프레임 [RFC8336]을 전송하여 제거할 수 있습니다.

요청 대상의 host 및 port 값은 각 HTTP 요청에 전달되어 오리진을 식별하고 동일한 서버가 제어할 수 있는 다른 네임스페이스와 구별합니다(7.2절). 인증서의 개인 키에 대한 제어권을 제공받은 모든 서비스가 대응하는 "https" 네임스페이스를 관리할 동등한 책임이 있거나, 최소한 잘못 전달된 것으로 보이는 요청을 거부할 준비가 되어 있도록 하는 것은 오리진의 책임입니다(7.4절).

오리진 서버는 그렇게 할 authority가 있더라도 특정 대상 URI에 대한 요청을 처리하지 않을 수 있습니다. 예를 들어 host가 서로 다른 포트(예: 443 및 8000)에서 별도의 서비스를 운영하는 경우, 네트워크 공격자가 한 포트에 대한 연결을 다른 포트에서 수신되도록 할 수 있으므로 연결이 보호된 후에도 오리진 서버에서 대상 URI를 확인해야 합니다. 대상 URI를 확인하지 않으면 그러한 공격자가 하나의 대상 URI(예: "https://example.com/foo")에 대한 응답을 다른 포트(예: "https://example.com:8000/foo")에서 온, 겉보기에는 권위 있는 응답으로 대체할 수 있습니다.

"https" 스킴은 authority를 연결할 때 TCP와 연결된 포트 번호에 의존하지 않습니다. 둘 다 보호된 통신 외부에 있으므로 결정적인 것으로 신뢰할 수 없기 때문입니다. 따라서 HTTP 통신은 4.2.2절에 정의된 대로 보호된 모든 채널에서 이루어질 수 있으며, 여기에는 TCP를 사용하지 않는 프로토콜도 포함됩니다.

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

서버가 그러한 요청에 15절에 설명된 비임시 HTTP 응답 메시지로 응답하면 해당 응답은 클라이언트의 요청에 대한 권위 있는 응답으로 간주됩니다.

그러나 위 방법이 권위 있는 응답을 얻는 유일한 수단은 아니며, 권위 있는 응답이 항상 필요하다는 의미도 아닙니다([CACHING] 참조).

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

일반적으로 클라이언트는 [RFC6125]의 6절에 정의된 검증 과정을 사용하여 서비스 식별성을 MUST 검증해야 합니다. 클라이언트는 서비스의 host에서 참조 식별성을 MUST 구성해야 합니다. host가 리터럴 IP 주소(4.3.5절)이면 참조 식별성은 IP-ID이고, 그렇지 않으면 host는 이름이며 참조 식별성은 DNS-ID입니다.

클라이언트는 CN-ID 유형의 참조 식별성을 MUST NOT 사용하지 마십시오. [RFC6125]의 6.2.1절에 언급된 대로, CN-ID 유형의 참조 식별성은 이전 클라이언트에서 사용될 수 있습니다.

클라이언트는 대체 형태의 서버 식별성 검증을 허용하도록 특별히 구성될 수 있습니다. 예를 들어 클라이언트는 주소와 host 이름이 동적인 서버에 연결하면서, 서비스가 대상 URI의 오리진과 일치하는 인증서 대신 특정 인증서(또는 외부에서 정의된 참조 식별성과 일치하는 인증서)를 제공할 것으로 예상할 수 있습니다.

특별한 경우 클라이언트가 서버의 식별성을 단순히 무시하는 것이 적절할 수 있지만, 그러면 연결이 능동적 공격에 노출된다는 점을 이해해야 합니다.

인증서가 대상 URI의 오리진에 유효하지 않은 경우 사용자 에이전트는 진행하기 전에 사용자에게 확인을 받거나(3.5절 참조) 잘못된 인증서 오류와 함께 연결을 종료하도록 MUST 해야 합니다. 자동화된 클라이언트는 오류를 적절한 감사 로그(사용 가능한 경우)에 MUST 기록하고 연결을 종료하는 것이 SHOULD 요구됩니다(잘못된 인증서 오류와 함께). 자동화된 클라이언트는 이 검사를 비활성화하는 구성 설정을 MAY 제공할 수 있지만, 이를 활성화하는 설정을 MUST 제공해야 합니다.

"https" URI의 "host" 필드에서 IP 주소 리터럴을 사용해 식별되는 서버는 IP-ID 유형의 참조 식별성을 갖습니다. IP 버전 4 주소는 "IPv4address" ABNF 규칙을 사용하고, IP 버전 6 주소는 "IPv6address" 옵션이 있는 "IP-literal" 생성식을 사용합니다. [URI]의 3.2.2절을 참조하십시오. IP-ID의 참조 식별성에는 IP 주소를 디코딩한 바이트가 포함됩니다.

IP 버전 4 주소는 4옥텟이고 IP 버전 6 주소는 16옥텟입니다. 다른 IP 버전에 대해서는 IP-ID 사용이 정의되지 않습니다. 인증서 subjectAltName 확장의 iPAddress 선택 항목은 IP 버전을 명시적으로 포함하지 않으므로 주소 길이에 의존하여 버전을 구분합니다. [RFC5280]의 4.2.1.6절을 참조하십시오.

IP-ID 유형의 참조 식별성은 주소가 인증서의 subjectAltName 확장에 있는 iPAddress 값과 동일하면 일치합니다.

[RFC5234]의 ABNF 규칙에 대한 #rule 확장은 일부 목록 기반 필드 값 정의의 가독성을 향상하는 데 사용됩니다.

쉼표로 구분된 요소 목록을 정의하기 위해 "*"와 유사한 "#" 구문이 정의됩니다. 전체 형식은 "<n>#<m>element"이며, 최소 <n>개에서 최대 <m>개의 요소를 나타내고 각 요소는 하나의 쉼표(",")와 선택적 공백(OWS, 5.6.3절에 정의됨)으로 구분됩니다.

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

  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; 구분자를 제외한 모든 VCHAR

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

이 사양은 선형 공백 사용을 나타내기 위해 세 가지 규칙을 사용합니다. OWS (선택적 공백), RWS (필수 공백), BWS ("잘못된" 공백).

OWS 규칙은 0개 이상의 선형 공백 옥텟이 나타날 수 있는 곳에 사용됩니다. 가독성을 높이기 위해 선택적 공백을 사용하는 것이 바람직한 프로토콜 요소에서는 송신자가 선택적 공백을 하나의 SP로 생성하는 것이 SHOULD 요구됩니다. 그렇지 않은 경우 송신자는 인플레이스 메시지 필터링 중 유효하지 않거나 원하지 않는 프로토콜 요소를 덮어쓰는 데 필요한 경우를 제외하고 선택적 공백을 생성하지 않는 것이 SHOULD NOT 요구됩니다.

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

OWS와 RWS는 하나의 SP와 동일한 의미론을 가집니다. OWS 또는 RWS로 정의된 것으로 알려진 모든 콘텐츠는 이를 해석하거나 메시지를 다운스트림으로 전달하기 전에 하나의 SP로 MAY 대체할 수 있습니다.

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

BWS에는 의미론이 없습니다. BWS로 정의된 것으로 알려진 모든 콘텐츠는 이를 해석하거나 메시지를 다운스트림으로 전달하기 전에 제거할 수 MAY 있습니다.

  OWS            = *( SP / HTAB )
                 ; 선택적 공백
  RWS            = 1*( SP / HTAB )
                 ; 필수 공백
  BWS            = OWS
                 ; "잘못된" 공백

텍스트 문자열은 큰따옴표로 인용된 경우 하나의 값으로 구문 분석됩니다.

  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 생성식과 일치하는 매개변수 값은 token으로 또는 quoted-string 안에서 전송할 수 있습니다. 인용된 값과 인용되지 않은 값은 동등합니다.

1995년 이전에는 서버가 타임스탬프를 전달하는 데 일반적으로 사용하는 세 가지 형식이 있었습니다. 이전 구현과의 호환성을 위해 세 형식 모두 여기에서 정의됩니다. 선호되는 형식은 인터넷 메시지 형식 [RFC5322]에서 사용하는 날짜 및 시간 사양의 고정 길이 단일 시간대 하위 집합입니다.

  HTTP-date    = IMF-fixdate / obs-date

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

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

폐기된 두 형식의 예는 다음과 같습니다.

Sunday, 06-Nov-94 08:49:37 GMT   ; 폐기된 RFC 850 형식
Sun Nov  6 08:49:37 1994         ; ANSI C의 asctime() 형식

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

HTTP-date 값은 시간을 협정 세계시 (UTC)의 한 시점으로 나타냅니다. 처음 두 형식은 UTC 명칭의 전신인 그리니치 평균시의 세 글자 약어 "GMT"로 UTC를 나타냅니다. asctime 형식의 값은 UTC인 것으로 간주됩니다.

시계는 현재 UTC 시점의 합리적인 근삿값을 제공할 수 있는 구현입니다. 시계 구현은 UTC와 동기화하기 위해 NTP ([RFC5905]) 또는 이와 유사한 프로토콜을 사용하는 것이 바람직합니다.

  IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  ; 형식의 고정 길이/시간대/대문자 표기 하위 집합
  ; [RFC5322]의 3.3절 참조

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

  date1        = day SP month SP year
               ; 예: 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 (윤초)

  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
               ; 예: 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 ))
               ; 예: Jun  2

HTTP-date는 대소문자를 구분합니다. [CACHING]의 4.2절은 캐시 수신자에 대해 이를 완화한다는 점에 유의하십시오.

송신자는 문법에서 SP로 명시적으로 포함된 것 외에 HTTP-date에 추가 공백을 MUST NOT 생성하지 마십시오. day-name, day, month, year 및 time-of-day의 의미론은 같은 이름의 인터넷 메시지 형식 구문에 대해 정의된 것과 동일합니다([RFC5322], 3.3절).

두 자리 연도를 사용하는 rfc850-date 형식의 타임스탬프 값을 수신한 수신자는 현재보다 50년 넘게 미래인 것으로 보이는 타임스탬프를 마지막 두 자리가 같은 가장 최근의 과거 연도를 나타내는 것으로 MUST 해석해야 합니다.

타임스탬프 값의 수신자는 필드 정의에서 달리 제한하지 않는 한 타임스탬프를 견고하게 구문 분석하는 것이 권장됩니다. 예를 들어 메시지는 인터넷 메시지 형식에서 정의한 날짜 및 시간 사양 중 하나를 생성할 수 있는 비 HTTP 소스에서 HTTP를 통해 전달되기도 합니다.

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

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

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

GET에 대한 206 (부분 콘텐츠) 응답의 콘텐츠는 선택된 표현의 단일 부분 또는 해당 표현의 여러 부분을 포함하는 멀티파트 메시지 본문을 포함하며, 이는 15.3.7절에 설명되어 있습니다.

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

HEAD 요청 메서드(9.3.2절)에 대한 응답에는 콘텐츠가 포함되지 않습니다. 관련 응답 헤더 필드는 요청 메서드가 GET(9.3.1절)이었다면 그 값이 무엇이었을지만 나타냅니다.

CONNECT 요청 메서드(9.3.6절)에 대한 2xx (성공) 응답은 콘텐츠를 갖는 대신 연결을 터널 모드로 전환합니다.

모든 1xx (정보성), 204 (콘텐츠 없음) 및 304 (수정되지 않음) 응답에는 콘텐츠가 포함되지 않습니다.

그 밖의 모든 응답에는 콘텐츠가 포함되지만, 해당 콘텐츠의 길이는 0일 수 있습니다.

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

• 요청에 Content-Location 헤더 필드가 있으면, 송신자는 콘텐츠가 Content-Location 필드 값으로 식별되는 리소스의 표현이라고 주장합니다. 그러나 그러한 주장은 다른 수단(이 사양에서는 정의하지 않음)으로 검증할 수 없는 한 신뢰할 수 없습니다. 이 정보는 개정 이력 링크에는 여전히 유용할 수 있습니다.
• 그렇지 않으면 콘텐츠는 HTTP에 의해 식별되지 않지만, 더 구체적인 식별자가 콘텐츠 자체에 제공될 수 있습니다.

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

트레일러 섹션은 사용 중인 HTTP 버전에서 지원되고 명시적 프레이밍 메커니즘으로 활성화된 경우에만 가능합니다. 예를 들어 HTTP/1.1의 청크 전송 코딩은 콘텐츠 뒤에 트레일러 섹션을 전송할 수 있도록 합니다( [HTTP/1.1]의 7.1.2절).

메시지 프레이밍, 라우팅, 인증, 요청 수정자, 응답 제어 또는 콘텐츠 형식을 설명하는 필드처럼 콘텐츠를 수신하기 전에 평가해야 하므로 많은 필드는 헤더 섹션 밖에서 처리할 수 없습니다. 송신자는 대응하는 헤더 필드 이름의 정의가 해당 필드를 트레일러에서 전송할 수 있도록 허용한다는 것을 알고 있지 않는 한 트레일러 필드를 MUST NOT 생성해야 합니다.

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

요청의 TE 헤더 필드(10.1.4절)에 "trailers" 키워드가 있으면 클라이언트가 자신과 모든 다운스트림 클라이언트를 대신하여 트레일러 필드를 수락할 의향이 있음을 나타냅니다. 중개자가 보낸 요청의 경우 이는 모든 다운스트림 클라이언트가 전달된 응답에서 트레일러 필드를 수락할 의향이 있음을 의미합니다. "trailers"가 있다고 해서 클라이언트가 응답의 특정 트레일러 필드를 처리한다는 의미는 아니며, 단지 어떤 클라이언트도 트레일러 섹션을 버리지 않는다는 의미입니다.

트레일러 필드가 전송 중 버려질 가능성이 있으므로 서버는 사용자 에이전트가 수신해야 한다고 판단하는 트레일러 필드를 SHOULD NOT 생성하는 것이 좋습니다.

"Trailer" 헤더 필드(6.6.2절)는 트레일러 섹션에서 전송될 가능성이 있는 필드를 나타내기 위해 전송할 수 있으며, 이를 통해 수신자는 콘텐츠를 처리하기 전에 해당 필드의 수신에 대비할 수 있습니다. 예를 들어 필드 이름이 콘텐츠를 수신하는 동안 동적 체크섬을 계산하고 트레일러 필드 값을 수신하는 즉시 검사해야 함을 나타내는 경우 유용할 수 있습니다.

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

메시지 끝에서 수신자는 수신된 트레일러 필드 집합을 헤더 필드와 유사하지만 별개인 이름/값 쌍의 데이터 구조로 MAY 취급할 수 있습니다. 추가 처리 요구사항이 있다면 트레일러에서 사용하도록 의도된 필드의 필드 사양에 정의할 수 있습니다.

"Date" 헤더 필드는 메시지가 생성된 날짜와 시간을 나타내며, [RFC5322]의 3.6.1절에 정의된 Origination Date Field(orig-date)와 동일한 의미론을 가집니다. 필드 값은 5.6.7절에 정의된 HTTP-date입니다.

  Date = HTTP-date

예시는 다음과 같습니다.

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

Date 헤더 필드를 생성하는 송신자는 필드 값을 메시지 생성 날짜와 시간에 대한 가장 좋은 근삿값으로 SHOULD 생성해야 합니다. 이론적으로 날짜는 메시지 콘텐츠를 생성하기 직전의 시점을 나타내는 것이 바람직합니다. 실제로 송신자는 메시지 생성 중 언제든 날짜 값을 생성할 수 있습니다.

5.6.7절에 정의된 시계를 가진 오리진 서버는 모든 2xx (성공), 3xx (리디렉션) 및 4xx (클라이언트 오류) 응답에서 Date 헤더 필드를 MUST 생성해야 하며, 1xx (정보성) 및 5xx (서버 오류) 응답에서 Date 헤더 필드를 MAY 생성할 수 있습니다.

시계가 없는 오리진 서버는 Date 헤더 필드를 MUST NOT 생성해야 합니다.

시계가 있는 수신자가 Date 헤더 필드가 없는 응답 메시지를 수신한 경우 수신 시각을 MUST 기록하고 해당 메시지가 캐시되거나 다운스트림으로 전달되면 메시지의 헤더 섹션에 대응하는 Date 헤더 필드를 추가해야 합니다.

시계가 있는 수신자가 유효하지 않은 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절에서는 식별된 오리진 서버에 인바운드 연결을 설정(또는 재사용)하고 클라이언트의 대상 URI와 일치하는 요청 대상을 포함하는 HTTP 요청 메시지를 전송하여 "http" 리소스에 접근하는 방법을 정의합니다.

4.3.3절에서는 식별된 오리진에 권한이 있는 오리진 서버에 인바운드 보호 연결을 설정(또는 재사용)하고, 클라이언트의 대상 URI와 일치하는 요청 대상을 포함하는 HTTP 요청 메시지를 전송하여 "https" 리소스에 접근하는 방법을 정의합니다.

"Connection" 헤더 필드를 사용하면 송신자가 현재 연결에 원하는 제어 옵션을 나열할 수 있습니다.

  Connection        = #connection-option
  connection-option = token

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

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

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

따라서 Connection 헤더 필드는 즉시 수신자만을 대상으로 하는 필드("홉별")와 체인의 모든 수신자를 대상으로 하는 필드("종단 간")를 구분하는 선언적 방법을 제공하여 메시지가 자기 기술적이도록 하고 향후 연결별 확장이 이전 중개자에 의해 무분별하게 전달될 우려 없이 배포될 수 있도록 합니다.

• Proxy-Connection ( [HTTP/1.1]의 부록 C.2.2)
• Keep-Alive ( [RFC2068]의 19.7.1절)
• TE (10.1.4절)
• Transfer-Encoding ( [HTTP/1.1]의 6.1절)
• Upgrade (7.8절)

송신자는 콘텐츠의 모든 수신자를 대상으로 하는 필드에 대응하는 연결 옵션을 MUST NOT 전송해야 합니다. 예를 들어 Cache-Control은 연결 옵션으로 절대 적절하지 않습니다([CACHING]의 5.2절).

연결 옵션은 메시지에 존재하는 필드와 항상 대응하지는 않습니다. 연결 옵션과 관련된 매개변수가 없으면 연결별 필드가 필요하지 않을 수 있기 때문입니다. 반대로 대응하는 연결 옵션 없이 수신된 연결별 필드는 일반적으로 중개자가 필드를 부적절하게 전달했음을 나타내며 수신자는 이를 무시하는 것이 바람직합니다.

필드에 대응하지 않는 새로운 연결 옵션을 정의할 때 사양 작성자는 나중의 충돌을 피하기 위해 대응하는 필드 이름을 미리 예약하는 것이 바람직합니다. 이러한 예약된 필드 이름은 "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 값은 이 요청 메시지를 앞으로 전달할 수 있는 남은 횟수를 나타내는 십진 정수입니다.

Max-Forwards 헤더 필드를 포함하는 TRACE 또는 OPTIONS 요청을 수신한 각 중개자는 요청을 전달하기 전에 그 값을 확인하고 갱신하도록 MUST 해야 합니다. 수신된 값이 0이면 중개자는 요청을 전달하지 MUST NOT 해야 하며, 대신 중개자가 최종 수신자로서 MUST 응답해야 합니다. 수신된 Max-Forwards 값이 0보다 크면 중개자는 전달된 메시지에 갱신된 Max-Forwards 필드를 MUST 생성해야 하며, 그 필드 값은 a) 수신된 값을 1만큼 감소시킨 값 또는 b) 수신자가 지원하는 Max-Forwards의 최대값 중 더 작은 값이어야 합니다.

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

"Via" 헤더 필드는 요청의 경우 사용자 에이전트와 서버 사이, 응답의 경우 오리진 서버와 클라이언트 사이에 존재하는 중간 프로토콜 및 수신자를 나타내며, 이메일의 "Received" 헤더 필드( [RFC5322]의 3.6.7절)와 유사합니다. Via는 메시지 전달을 추적하고, 요청 루프를 방지하며, 요청/응답 체인에 있는 송신자의 프로토콜 기능을 식별하는 데 사용할 수 있습니다.

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

  received-protocol = [ protocol-name "/" ] protocol-version
                    ; 7.8절 참조
  received-by       = pseudonym [ ":" port ]
  pseudonym         = token

Via 필드 값의 각 멤버는 메시지를 전달한 프록시 또는 게이트웨이를 나타냅니다. 각 중개자는 메시지를 수신한 방법에 대한 자체 정보를 추가하므로 최종 결과는 전달 수신자의 순서에 따라 정렬됩니다.

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

각 중개자에 대해 received-protocol은 메시지의 업스트림 송신자가 사용한 프로토콜과 프로토콜 버전을 나타냅니다. 따라서 Via 필드 값은 요청/응답 체인의 알려진 프로토콜 기능을 기록하여 다운스트림 수신자가 계속 볼 수 있게 합니다. 이는 응답이나 이후 요청에서 어떤 하위 비호환 기능을 안전하게 사용할 수 있는지 결정하는 데 유용할 수 있으며, 2.5절에 설명되어 있습니다. 간결성을 위해 수신 프로토콜이 HTTP인 경우 protocol-name은 생략됩니다.

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

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

Via: 1.0 fred, 1.1 p.example.net

네트워크 방화벽을 통과하는 포털로 사용되는 중개자는 명시적으로 허용되지 않는 한 방화벽 영역 안의 host 이름과 port를 전달하지 않는 것이 SHOULD NOT 요구됩니다. 허용되지 않은 경우 그러한 중개자는 방화벽 뒤에 있는 host의 각 received-by host를 해당 host에 적절한 가명으로 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

송신자는 모든 멤버가 동일한 조직의 통제하에 있고 host가 이미 가명으로 대체된 경우가 아니면 여러 목록 멤버를 SHOULD NOT 결합해야 합니다. 송신자는 서로 다른 received-protocol 값을 가진 멤버를 MUST NOT 결합해야 합니다.

HTTP는 개방적이고 확장 가능한 데이터 타이핑 및 유형 협상을 제공하기 위해 Content-Type(8.3절) 및 Accept(12.5.1절) 헤더 필드에서 미디어 유형 [RFC2046]을 사용합니다. 미디어 유형은 데이터 형식과 메시지 컨텍스트에 따라 해당 데이터를 처리하는 방법을 나타내는 다양한 처리 모델을 모두 정의합니다.

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

type 및 subtype 토큰은 대소문자를 구분하지 않습니다.

type/subtype 뒤에는 이름/값 쌍 형식의 세미콜론으로 구분된 매개변수(5.6.6절)가 MAY 올 수 있습니다. 매개변수의 존재 여부는 미디어 유형 레지스트리 내 정의에 따라 미디어 유형 처리에 중요할 수 있습니다. 매개변수 값은 매개변수 이름의 의미론에 따라 대소문자를 구분할 수도 있고 구분하지 않을 수도 있습니다.

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

미디어 유형은 [BCP13]에 정의된 절차에 따라 IANA에 등록하는 것이 바람직합니다.

HTTP는 텍스트 표현의 문자 인코딩 체계([RFC6365], 2절)를 나타내거나 협상하기 위해 charset 이름을 사용합니다. 이 문서에서 정의하는 필드에서 charset 이름은 매개변수(Content-Type)에 나타나거나, Accept-Encoding의 경우 일반 token 형식으로 나타납니다. 두 경우 모두 charset 이름은 대소문자를 구분하지 않고 비교됩니다.

Charset 이름은 [RFC2978]의 2절에 정의된 절차에 따라 IANA "Character Sets" 레지스트리(https://www.iana.org/assignments/character-sets)에 등록하는 것이 바람직합니다.

MIME은 여러 "multipart" 유형, 즉 하나의 메시지 본문 안에 하나 이상의 표현을 캡슐화하는 유형을 제공합니다. 모든 멀티파트 유형은 [RFC2046]의 5.1.1절에 정의된 공통 구문을 공유하고, 미디어 유형 값의 일부로 boundary 매개변수를 포함합니다. 메시지 본문 자체가 프로토콜 요소이므로 송신자는 본문 부분 사이의 줄 바꿈을 나타내는 데 CRLF만 MUST 생성해야 합니다.

HTTP 메시지 프레이밍은 멀티파트 boundary를 메시지 본문 길이의 표시로 사용하지 않지만, 콘텐츠를 생성하거나 처리하는 구현에서 사용할 수 있습니다. 예를 들어 "multipart/form-data" 유형은 [RFC7578]에 설명된 대로 요청에서 양식 데이터를 전달하는 데 자주 사용되며, "multipart/byteranges" 유형은 이 사양에서 일부 206 (부분 콘텐츠) 응답에 사용하도록 정의됩니다(15.3.7절 참조).

콘텐츠 코딩 값은 표현에 적용되었거나 적용될 수 있는 인코딩 변환을 나타냅니다. 콘텐츠 코딩은 기본 미디어 유형의 식별성과 정보를 잃지 않으면서 표현을 압축하거나 다른 유용한 방식으로 변환할 수 있도록 하는 데 주로 사용됩니다. 흔히 표현은 코딩된 형식으로 저장되고 직접 전송된 다음 최종 수신자에 의해서만 디코딩됩니다.

  content-coding   = token

모든 콘텐츠 코딩은 대소문자를 구분하지 않으며 16.6절에 설명된 대로 "HTTP Content Coding Registry"에 등록하는 것이 바람직합니다.

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

[RFC5646]에 정의된 언어 태그는 인간이 다른 인간에게 정보를 전달하기 위해 말하거나 쓰거나 그 밖의 방식으로 표현하는 자연어를 식별합니다. 컴퓨터 언어는 명시적으로 제외됩니다.

HTTP는 Accept-Language 및 Content-Language 헤더 필드에서 언어 태그를 사용합니다. Accept-Language는 12.5.4절에 정의된 더 넓은 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) 응답의 콘텐츠에서 관찰 가능한 표현 데이터의 변경이 발생할 때마다 값이 변경되는 표현 메타데이터입니다.

강한 검증자는 표현 데이터의 변경 이외의 이유로도 변경될 수 있습니다. 예를 들어 표현 메타데이터의 의미론적으로 중요한 부분(Content-Type)이 변경되는 경우입니다. 그러나 원격 캐시와 작성 도구에 저장된 응답을 무효화해야 할 때만 값을 변경하는 것이 오리진 서버에 가장 유리합니다.

캐시 항목은 만료 시간과 관계없이 임의로 긴 기간 동안 유지될 수 있습니다. 따라서 캐시는 아주 오래전에 얻은 검증자를 사용하여 항목을 검증하려 할 수 있습니다. 강한 검증자는 시간이 지나는 동안 특정 리소스와 관련된 모든 표현의 모든 버전에 걸쳐 고유합니다. 그러나 서로 다른 리소스의 표현 사이에서도 고유하다는 의미는 없습니다(즉, 동일한 강한 검증자가 여러 리소스의 표현에 동시에 사용될 수 있으며, 그렇다고 해당 표현들이 동등하다는 의미는 아닙니다).

실제로 다양한 강한 검증자가 사용됩니다. 가장 좋은 것은 엄격한 개정 제어를 기반으로 하며, 표현의 각 변경마다 GET으로 표현에 접근할 수 있게 되기 전에 고유한 노드 이름과 개정 식별자가 항상 할당됩니다. 표현 데이터에 적용한 충돌 저항 해시 함수도 응답 헤더 필드가 전송되기 전에 데이터를 사용할 수 있고 검증 요청이 수신될 때마다 다이제스트를 다시 계산할 필요가 없다면 충분합니다. 그러나 리소스에 메타데이터만 다른 서로 다른 표현이 있는 경우, 예를 들어 동일한 데이터 형식을 공유하는 미디어 유형 간 콘텐츠 협상에서 발생할 수 있는 경우 오리진 서버는 해당 표현을 구별하기 위한 추가 정보를 검증자에 포함해야 합니다.

반대로 약한 검증자는 표현 데이터가 변경될 때마다 변경되지 않을 수 있는 표현 메타데이터입니다. 이러한 약점은 값 계산 방식의 제한(예: 시계 해상도), 가능한 모든 리소스 표현에 대해 고유성을 보장할 수 없음, 또는 리소스 소유자가 고유한 데이터 시퀀스 대신 스스로 정한 동등성 집합에 따라 표현을 그룹화하려는 의도 때문에 발생할 수 있습니다.

오리진 서버는 이전 표현이 현재 표현의 대체물로 허용되지 않는다고 판단할 때마다 약한 엔터티 태그를 SHOULD 변경해야 합니다. 즉 약한 엔터티 태그는 오리진 서버가 캐시에 오래된 응답을 무효화하도록 하려는 때마다 변경하는 것이 바람직합니다.

예를 들어 동적 측정값에 따라 콘텐츠가 매초 변경되는 일기예보 표현은 캐시된 표현이 합리적인 기간 동안 유효하도록 동일한 약한 검증자를 가진 동등한 표현 집합(오리진 서버의 관점에서)으로 그룹화할 수 있습니다 (서버 부하 또는 날씨 품질에 따라 동적으로 조정할 수도 있음). 마찬가지로 표현 수정 시간이 1초 해상도로만 정의되어 있고 한 초 안에 표현이 두 번 수정되고 그 수정 사이에 검색될 수 있다면 약한 검증자가 될 수 있습니다.

마찬가지로 검증자가 특정 리소스의 둘 이상의 표현에서 동시에 공유되고 해당 표현들의 표현 데이터가 동일하지 않다면 약한 검증자입니다. 예를 들어 오리진 서버가 gzip 콘텐츠 코딩이 적용된 표현과 콘텐츠 코딩이 없는 표현에 동일한 검증자를 전송한다면 그 검증자는 약합니다. 그러나 두 개의 동시 표현이 동일한 표현 데이터에 대해 서로 다른 두 미디어 유형을 사용할 때와 같이 표현 메타데이터만 다르다면 동일한 강한 검증자를 공유할 수 있습니다.

강한 검증자는 캐시 검증, 부분 콘텐츠 범위 및 "업데이트 손실" 방지를 포함한 모든 조건부 요청에 사용할 수 있습니다. 약한 검증자는 이전에 얻은 표현 데이터와 정확히 동일할 필요가 없는 경우에만 사용할 수 있습니다. 예를 들어 캐시 항목을 검증하거나 웹 탐색을 최근 변경 사항으로 제한할 때입니다.

응답의 "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와 obs-text

엔터티 태그는 수정 날짜를 저장하기 불편하거나, HTTP-date 값의 1초 해상도가 충분하지 않거나, 수정 날짜가 일관되게 유지되지 않는 상황에서 수정 날짜보다 더 신뢰할 수 있는 검증자가 될 수 있습니다.

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

엔터티 태그는 약한 검증자 또는 강한 검증자가 될 수 있으며 기본값은 강한 검증자입니다. 오리진 서버가 표현에 엔터티 태그를 제공하고 해당 엔터티 태그의 생성이 강한 검증자(8.8.1절)의 모든 특성을 충족하지 못한다면, 오리진 서버는 불투명 값 앞에 "W/"(대소문자 구분)를 붙여 엔터티 태그를 약한 것으로 MUST 표시해야 합니다.

송신자는 트레일러 섹션에서 ETag 필드를 MAY 전송할 수 있습니다(6.5절 참조). 그러나 트레일러는 자주 무시되므로 콘텐츠를 전송하는 동안 엔터티 태그가 생성되는 경우가 아니라면 ETag를 헤더 필드로 전송하는 것이 바람직합니다.

정의된 의미론이 본질적으로 읽기 전용이면 요청 메서드는 안전한 것으로 간주됩니다. 즉 클라이언트는 대상 리소스에 안전한 메서드를 적용한 결과로 오리진 서버에서 어떠한 상태 변경도 요청하지 않고 기대하지도 않습니다. 마찬가지로 안전한 메서드를 합리적으로 사용해도 오리진 서버에 피해, 재산 손실 또는 비정상적인 부담을 일으킬 것으로 예상되지 않습니다.

안전한 메서드에 대한 이 정의는 구현이 잠재적으로 해롭거나 완전히 읽기 전용이 아니거나 안전한 메서드를 호출할 때 부작용을 일으키는 동작을 포함하는 것을 막지 않습니다. 그러나 중요한 점은 클라이언트가 그러한 추가 동작을 요청하지 않았으므로 그에 대한 책임을 질 수 없다는 것입니다. 예를 들어 대부분의 서버는 메서드와 관계없이 모든 응답이 완료될 때 요청 정보를 접근 로그 파일에 추가하며, 로그 저장소가 가득 차서 서버가 실패할 수 있더라도 이는 안전한 것으로 간주됩니다. 마찬가지로 웹에서 광고를 선택해 시작된 안전한 요청은 광고 계정에 비용을 청구하는 부작용을 갖는 경우가 많습니다.

이 사양에서 정의한 요청 메서드 중 GET, HEAD, OPTIONS 및 TRACE 메서드는 안전한 것으로 정의됩니다.

안전한 메서드와 안전하지 않은 메서드를 구별하는 목적은 자동화된 검색 프로세스(스파이더)와 캐시 성능 최적화(미리 가져오기)가 피해를 일으킬 우려 없이 작동할 수 있도록 하는 것입니다. 또한 사용자 에이전트가 잠재적으로 신뢰할 수 없는 콘텐츠를 처리할 때 안전하지 않은 메서드의 자동 사용에 적절한 제한을 적용할 수 있도록 합니다.

사용자 에이전트는 사용자에게 가능한 작업을 제시할 때 안전한 메서드와 안전하지 않은 메서드를 SHOULD 구별하여, 안전하지 않은 작업을 요청하기 전에 사용자가 이를 알 수 있도록 해야 합니다.

대상 URI 안의 매개변수가 작업을 선택하는 효과를 갖도록 리소스가 구성된 경우, 해당 작업이 요청 메서드 의미론과 일치하도록 하는 것은 리소스 소유자의 책임입니다. 예를 들어 웹 기반 콘텐츠 편집 소프트웨어에서는 "page?do=delete"와 같이 쿼리 매개변수 안에 작업을 사용하는 경우가 흔합니다. 이러한 리소스의 목적이 안전하지 않은 작업을 수행하는 것이라면 리소스 소유자는 안전한 요청 메서드로 접근될 때 해당 작업을 MUST 비활성화하거나 허용하지 않아야 합니다. 그렇게 하지 않으면 자동화된 프로세스가 링크 유지 관리, 미리 가져오기, 검색 색인 구축 등을 위해 모든 URI 참조에 GET을 수행할 때 바람직하지 않은 부작용이 발생합니다.

동일한 메서드로 여러 번 같은 요청을 보냈을 때 서버에 의도된 효과가 그러한 요청을 한 번 보냈을 때의 효과와 같으면 요청 메서드는 멱등으로 간주됩니다. 이 사양에서 정의된 요청 메서드 중 PUT, DELETE 및 안전한 요청 메서드는 멱등입니다.

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

멱등 메서드는 클라이언트가 서버의 응답을 읽기 전에 통신 실패가 발생하면 요청을 자동으로 반복할 수 있기 때문에 구별됩니다. 예를 들어 클라이언트가 PUT 요청을 전송했는데 응답을 받기 전에 기본 연결이 닫히면 클라이언트는 새 연결을 설정하고 멱등 요청을 다시 시도할 수 있습니다. 원래 요청이 성공했더라도 요청을 반복하면 의도된 효과는 동일하다는 것을 알고 있지만 응답은 다를 수 있습니다.

클라이언트는 메서드와 관계없이 요청 의미론이 실제로 멱등임을 알 수 있는 수단이나 원래 요청이 전혀 적용되지 않았음을 감지할 수 있는 수단이 없다면 비멱등 메서드 요청을 자동으로 다시 시도하지 않는 것이 SHOULD NOT 요구됩니다.

예를 들어 사용자 에이전트는 요청이 해당 리소스에 안전하다는 것을 (설계 또는 구성을 통해) 알고 있으면 POST 요청을 자동으로 반복할 수 있습니다. 마찬가지로 버전 관리 저장소를 대상으로 특별히 작동하도록 설계된 사용자 에이전트는 실패한 연결 후 대상 리소스의 개정을 확인하고, 부분적으로 적용된 변경을 되돌리거나 수정한 다음 실패한 요청을 자동으로 다시 시도하여 부분 실패 상태에서 복구할 수 있습니다.

일부 클라이언트는 더 위험한 접근 방식을 취해 자동 재시도가 가능한 시점을 추측하려 합니다. 예를 들어 클라이언트는 응답의 어떤 부분도 수신하기 전에 기본 전송 연결이 닫힌 경우, 특히 유휴 영구 연결을 사용했다면 POST 요청을 자동으로 다시 시도할 수 있습니다.

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

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

이 사양은 GET, HEAD 및 POST에 대한 캐싱 의미론을 정의하지만 대부분의 캐시 구현은 GET과 HEAD만 지원합니다.

GET 메서드는 대상 리소스에 대한 현재 선택된 표현의 전송을 요청합니다. 성공적인 응답은 대상 URI로 식별되는 "동일성"의 품질을 반영합니다( [URI]의 1.2.2절). 따라서 HTTP를 통해 식별 가능한 정보를 검색하는 것은 일반적으로 200 (OK) 응답에서 해당 정보를 제공할 가능성과 관련된 식별자에 GET 요청을 수행하여 이루어집니다.

GET은 정보 검색의 주된 메커니즘이며 거의 모든 성능 최적화의 초점입니다. 중요한 각 리소스에 대해 URI를 생성하는 애플리케이션은 그러한 최적화의 이점을 얻으면서 다른 애플리케이션이 이를 재사용할 수 있게 하여 웹의 추가 확장을 촉진하는 네트워크 효과를 만듭니다.

리소스 식별자를 원격 파일 시스템 경로명으로, 표현을 그러한 파일 콘텐츠의 사본으로 생각하기 쉽습니다. 실제로 많은 리소스가 그렇게 구현됩니다(관련 보안 고려사항은 17.3절 참조). 그러나 실제로 그러한 제한은 없습니다.

리소스를 위한 HTTP 인터페이스는 콘텐츠 객체의 트리, 다양한 데이터베이스 레코드의 프로그램적 뷰 또는 다른 정보 시스템으로 연결되는 게이트웨이로 구현될 가능성도 높습니다. URI 매핑 메커니즘이 파일 시스템에 연결되어 있더라도 오리진 서버는 요청을 입력으로 사용해 파일을 실행하고 파일을 직접 전송하는 대신 출력을 표현으로 전송하도록 구성될 수 있습니다. 어떤 경우든 각 리소스 식별자가 구현에 대응하는 방식과 해당 구현이 대상 리소스의 현재 표현을 선택하고 전송하는 방법은 오리진 서버만 알면 됩니다.

클라이언트는 요청에 Range 헤더 필드를 전송하여 GET의 의미론을 "범위 요청"으로 변경하고 선택된 표현의 일부만 전송하도록 요청할 수 있습니다(14.2절).

요청 메시지 프레이밍은 사용된 메서드와 독립적이지만 GET 요청에서 수신된 콘텐츠에는 일반적으로 정의된 의미론이 없으며, 요청의 의미나 대상을 변경할 수 없고, 요청 스머글링 공격의 가능성 때문에 일부 구현이 요청을 거부하고 연결을 닫게 할 수 있습니다([HTTP/1.1]의 11.2절). 클라이언트는 그러한 요청이 목적을 가지고 충분히 지원될 것임을 이전에 대역 내 또는 대역 외로 나타낸 오리진 서버에 직접 요청하는 경우가 아니라면 GET 요청에 콘텐츠를 SHOULD NOT 생성해야 합니다. 오리진 서버는 콘텐츠를 수신하기 위해 비공개 합의에 의존하지 않는 것이 SHOULD NOT 요구됩니다. HTTP 통신의 참여자는 요청 체인에 있는 중개자를 모르는 경우가 많기 때문입니다.

GET 요청에 대한 응답은 캐시 가능합니다. [CACHING]의 5.2절에 정의된 Cache-Control 헤더 필드에서 달리 표시하지 않는 한 캐시는 후속 GET 및 HEAD 요청을 충족하는 데 이를 MAY 사용할 수 있습니다.

GET을 사용하는 양식의 쿼리 필드와 같이 사용자가 제공한 정보로 대상 URI를 구성하는 메커니즘으로 정보 검색을 수행할 때 URI 안에서 공개하기에 적절하지 않은 잠재적으로 민감한 데이터가 제공될 수 있습니다(17.9절 참조). 어떤 경우에는 그러한 정보를 드러내지 않도록 데이터를 필터링하거나 변환할 수 있습니다. 다른 경우, 특히 응답을 캐싱해 얻는 이점이 없는 경우에는 GET 대신 POST 메서드(9.3.3절)를 사용하면 그러한 정보를 대상 URI가 아닌 요청 콘텐츠로 전송할 수 있습니다.

HEAD 메서드는 서버가 응답에 콘텐츠를 MUST NOT 전송해야 한다는 점을 제외하면 GET과 동일합니다. HEAD는 표현 데이터를 전송하지 않고 선택된 표현에 관한 메타데이터를 얻는 데 사용되며, 흔히 하이퍼텍스트 링크를 검사하거나 최근 수정 사항을 찾기 위해 사용됩니다.

서버는 요청 메서드가 GET이었다면 전송했을 것과 동일한 헤더 필드를 HEAD 요청에 대한 응답에서도 SHOULD 전송해야 합니다. 그러나 콘텐츠를 생성하는 동안에만 값이 결정되는 헤더 필드는 서버가 MAY 생략할 수 있습니다. 예를 들어 일부 서버는 소량의 응답을 더 효율적으로 구분하거나 콘텐츠 선택에 관한 늦은 결정을 내릴 수 있도록 최소한의 데이터가 생성될 때까지 동적인 GET 응답을 버퍼링합니다. 이러한 GET 응답에는 예를 들어 HEAD 응답에서는 생성되지 않는 Content-Length 및 Vary 필드가 포함될 수 있습니다. HEAD는 일반적으로 효율성을 위해 요청되므로 이러한 사소한 불일치는 HEAD 요청에 대한 콘텐츠를 생성한 뒤 버리는 것보다 바람직한 것으로 간주됩니다.

요청 메시지 프레이밍은 사용된 메서드와 독립적이지만 HEAD 요청에서 수신된 콘텐츠에는 일반적으로 정의된 의미론이 없으며, 요청의 의미나 대상을 변경할 수 없고, 요청 스머글링 공격의 가능성 때문에 일부 구현이 요청을 거부하고 연결을 닫게 할 수 있습니다([HTTP/1.1]의 11.2절). 클라이언트는 그러한 요청이 목적을 가지고 충분히 지원될 것임을 이전에 대역 내 또는 대역 외로 나타낸 오리진 서버에 직접 요청하는 경우가 아니라면 HEAD 요청에 콘텐츠를 SHOULD NOT 생성해야 합니다. 오리진 서버는 콘텐츠를 수신하기 위해 비공개 합의에 의존하지 않는 것이 SHOULD NOT 요구됩니다. HTTP 통신의 참여자는 요청 체인에 있는 중개자를 모르는 경우가 많기 때문입니다.

HEAD 요청에 대한 응답은 캐시 가능합니다. [CACHING]의 5.2절에 정의된 Cache-Control 헤더 필드에서 달리 표시하지 않는 한 캐시는 후속 HEAD 요청을 충족하는 데 이를 MAY 사용할 수 있습니다. HEAD 응답은 이전에 캐시된 GET 응답에도 영향을 줄 수 있습니다. [CACHING]의 4.3.5절을 참조하십시오.

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

오리진 서버는 POST 요청 처리 결과에 따라 적절한 상태 코드를 선택하여 응답 의미론을 나타냅니다. 이 사양에서 정의하는 거의 모든 상태 코드를 POST에 대한 응답으로 받을 수 있습니다(예외는 206 (부분 콘텐츠), 304 (수정되지 않음) 및 416 (만족할 수 없는 범위)입니다).

POST 요청을 성공적으로 처리한 결과 오리진 서버에 하나 이상의 리소스가 생성되었다면, 오리진 서버는 생성된 주 리소스의 식별자를 제공하는 Location 헤더 필드(10.2.2절)와 새 리소스를 참조하면서 요청의 상태를 설명하는 표현을 포함하는 201 (생성됨) 응답을 SHOULD 전송해야 합니다.

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

POST 처리 결과가 기존 리소스의 표현과 동등하다면 오리진 서버는 Location 필드에 기존 리소스의 식별자를 포함하는 303 (다른 위치 참조) 응답을 전송하여 사용자 에이전트를 해당 리소스로 MAY 리디렉션할 수 있습니다. 이 방법은 사용자 에이전트에 리소스 식별자를 제공하고 공유 캐싱에 더 적합한 메서드를 통해 표현을 전송할 수 있다는 이점이 있지만, 사용자 에이전트가 표현을 이미 캐시하지 않은 경우 추가 요청이 필요하다는 비용이 있습니다.

PUT 메서드는 대상 리소스의 상태를 요청 메시지 콘텐츠에 포함된 표현이 정의하는 상태로 생성하거나 대체하도록 요청합니다. 특정 표현의 PUT이 성공했다면 동일한 대상 리소스에 대한 후속 GET은 200 (OK) 응답으로 동등한 표현을 전송할 것임을 시사합니다. 그러나 대상 리소스가 다른 사용자 에이전트에 의해 병렬로 처리되거나 후속 GET이 수신되기 전에 오리진 서버에서 동적인 처리를 받을 수 있으므로 그러한 상태 변경이 관찰 가능하다는 보장은 없습니다. 성공적인 응답은 오리진 서버가 요청을 처리한 시점에 사용자 에이전트의 의도가 달성되었음을 의미할 뿐입니다.

대상 리소스에 현재 표현이 없고 PUT이 성공적으로 하나를 생성한다면 오리진 서버는 201 (생성됨) 응답을 전송하여 사용자 에이전트에 이를 MUST 알려야 합니다. 대상 리소스에 현재 표현이 있고 포함된 표현의 상태에 따라 해당 표현이 성공적으로 수정된다면 오리진 서버는 요청의 성공적인 완료를 나타내기 위해 200 (OK) 또는 204 (콘텐츠 없음) 응답 중 하나를 MUST 전송해야 합니다.

오리진 서버는 PUT 표현이 대상 리소스에 대해 구성된 제약 조건과 일치하는지 SHOULD 확인해야 합니다. 예를 들어 오리진 서버가 URI를 기반으로 리소스의 표현 메타데이터를 결정한다면 성공적인 PUT 요청으로 수신된 콘텐츠가 해당 메타데이터와 일치하는지 확인해야 합니다. PUT 표현이 대상 리소스와 일치하지 않는 경우 오리진 서버는 표현을 변환하거나 리소스 구성을 변경하여 둘을 일치시키거나, 표현이 부적절한 이유를 설명할 충분한 정보가 포함된 적절한 오류 메시지로 응답하는 것이 SHOULD 요구됩니다. 409 (충돌) 또는 415 (지원되지 않는 미디어 유형) 상태 코드가 권장되며, 후자는 Content-Type 값에 대한 제약에 특화되어 있습니다.

1. 새 미디어 유형을 반영하도록 대상 리소스를 다시 구성하거나,
2. 새 리소스 상태로 저장하기 전에 PUT 표현을 리소스 형식과 일치하는 형식으로 변환하거나,
3. 대상 리소스가 "text/html"로 제한됨을 나타내는 415 (지원되지 않는 미디어 유형) 응답으로 요청을 거부하며, 새 표현에 적합한 대상이 될 다른 리소스에 대한 링크를 포함할 수 있습니다.

HTTP는 사용자 에이전트 요청의 의도와 오리진 서버 응답의 의미론으로 표현할 수 있는 범위를 넘어 PUT 메서드가 오리진 서버의 상태에 정확히 어떤 영향을 주는지 정의하지 않습니다. HTTP를 통해 제공되는 인터페이스를 넘어 리소스가 무엇일 수 있는지도 어떤 의미에서도 정의하지 않습니다. 리소스 상태가 어떻게 "저장"되는지, 리소스 상태 변경으로 그러한 저장소가 어떻게 변경될 수 있는지, 오리진 서버가 리소스 상태를 표현으로 변환하는 방법도 정의하지 않습니다. 일반적으로 리소스 인터페이스 뒤의 모든 구현 세부 사항은 서버에 의해 의도적으로 숨겨집니다.

이는 헤더 및 트레일러 필드가 저장되는 방식에도 적용됩니다. Content-Type 같은 일반적인 헤더 필드는 보통 저장되고 이후 GET 요청에서 반환되지만, 헤더와 트레일러 필드 처리는 요청을 수신한 리소스에 따라 다릅니다. 따라서 오리진 서버는 PUT 요청에서 수신한 인식되지 않는 헤더 및 트레일러 필드를 SHOULD 무시해야 합니다(즉, 리소스 상태의 일부로 저장하지 않아야 합니다).

오리진 서버는 요청의 표현 데이터가 콘텐츠에 아무런 변환도 적용하지 않고 저장되었고(즉, 리소스의 새 표현 데이터가 PUT 요청에서 수신된 콘텐츠와 동일함), 검증자 필드 값이 새 표현을 반영하는 경우가 아니라면 성공적인 PUT 응답에 8.8절의 검증자 필드, 예를 들어 ETag 또는 Last-Modified 필드를 MUST NOT 전송해야 합니다. 이 요구사항을 통해 사용자 에이전트는 자신이 전송하고 메모리에 유지한 표현이 PUT의 결과임을 알 수 있으므로 오리진 서버에서 다시 검색할 필요가 없습니다. 응답에서 수신한 새 검증자는 우발적인 덮어쓰기를 방지하기 위한 향후 조건부 요청에 사용할 수 있습니다(13.1절).

POST와 PUT 메서드의 근본적인 차이는 포함된 표현에 대한 서로 다른 의도에서 드러납니다. POST 요청의 대상 리소스는 포함된 표현을 리소스 자체의 의미론에 따라 처리하도록 의도되는 반면, PUT 요청에 포함된 표현은 대상 리소스의 상태를 대체하는 것으로 정의됩니다. 따라서 PUT의 의도는 멱등이며 중개자에게도 가시적이지만 정확한 효과는 오리진 서버만 알고 있습니다.

PUT 요청을 올바르게 해석하려면 사용자 에이전트가 어떤 대상 리소스를 원하는지 알고 있다고 전제합니다. 상태 변경 요청을 받은 후 클라이언트를 대신하여 적절한 URI를 선택하는 서비스는 PUT 대신 POST 메서드를 사용하여 구현하는 것이 SHOULD 요구됩니다. 오리진 서버가 대상 리소스에 요청된 PUT 상태 변경을 수행하지 않고 리소스가 다른 URI로 이동한 경우처럼 다른 리소스에 적용하려는 경우 오리진 서버는 적절한 3xx (리디렉션) 응답을 MUST 전송해야 합니다. 그러면 사용자 에이전트는 요청을 리디렉션할지 여부를 MAY 스스로 결정할 수 있습니다.

대상 리소스에 적용된 PUT 요청은 다른 리소스에 부작용을 줄 수 있습니다. 예를 들어 어떤 게시물에는 "현재 버전"(리소스)을 식별하는 URI가 있고, 각각의 특정 버전(한 시점에 현재 버전 리소스와 동일한 상태를 공유했던 다른 리소스)을 식별하는 URI와 별개일 수 있습니다. 따라서 "현재 버전" URI에 대한 성공적인 PUT 요청은 대상 리소스의 상태를 변경하는 것 외에도 새 버전 리소스를 생성할 수 있으며, 관련 리소스 사이에 링크가 추가되도록 할 수도 있습니다.

일부 오리진 서버는 Content-Range 헤더 필드(14.4절)를 14.5절에 설명된 부분 PUT을 수행하기 위한 요청 수정자로 사용하는 것을 지원합니다.

PUT 메서드에 대한 응답은 캐시할 수 없습니다. 성공적인 PUT 요청이 대상 URI에 대해 하나 이상의 저장된 응답을 가진 캐시를 통과하면 해당 저장된 응답은 무효화됩니다([CACHING]의 4.4절 참조).

DELETE 메서드는 오리진 서버가 대상 리소스와 현재 기능 사이의 연결을 제거하도록 요청합니다. 사실상 이 메서드는 UNIX의 "rm" 명령과 유사합니다. 이전에 연결된 정보 자체가 삭제될 것이라는 기대보다는 오리진 서버의 URI 매핑에 대한 삭제 작업을 나타냅니다.

대상 리소스에 하나 이상의 현재 표현이 있다면 리소스의 성격과 오리진 서버의 구현에 따라 오리진 서버가 이를 파기할 수도 있고 하지 않을 수도 있으며, 관련 저장소를 회수할 수도 있고 하지 않을 수도 있습니다(이는 이 사양의 범위를 벗어남). 마찬가지로 데이터베이스 또는 게이트웨이 연결과 같은 리소스의 다른 구현 측면도 DELETE의 결과로 비활성화되거나 보관되어야 할 수 있습니다. 일반적으로 오리진 서버는 삭제를 수행하기 위한 정해진 메커니즘이 있는 리소스에 대해서만 DELETE를 허용한다고 가정합니다.

DELETE 메서드를 허용하는 리소스는 비교적 적습니다. 주된 용도는 사용자가 그 효과를 어느 정도 제어하는 원격 작성 환경입니다. 예를 들어 이전에 PUT 요청으로 생성되었거나 POST 요청에 대한 201 (생성됨) 응답 후 Location 헤더 필드로 식별된 리소스는 그러한 작업을 되돌리기 위한 대응 DELETE 요청을 허용할 수 있습니다. 마찬가지로 HTTP를 원격 작업에 사용하는 버전 관리 클라이언트와 같이 작성 기능을 구현하는 사용자 지정 사용자 에이전트는 서버의 URI 공간이 버전 저장소에 대응하도록 구성되었다는 가정하에 DELETE를 사용할 수 있습니다.

DELETE 메서드가 성공적으로 적용되면 오리진 서버는 다음 중 하나를 SHOULD 전송해야 합니다.

• 작업이 성공할 가능성이 높지만 아직 수행되지 않았다면 202 (수락됨) 상태 코드,
• 작업이 수행되었고 추가 정보를 제공하지 않는다면 204 (콘텐츠 없음) 상태 코드, 또는
• 작업이 수행되었고 응답 메시지에 상태를 설명하는 표현이 포함된다면 200 (OK) 상태 코드

요청 메시지 프레이밍은 사용된 메서드와 독립적이지만 DELETE 요청에서 수신된 콘텐츠에는 일반적으로 정의된 의미론이 없으며, 요청의 의미나 대상을 변경할 수 없고, 요청 스머글링 공격의 가능성 때문에 일부 구현이 요청을 거부하고 연결을 닫게 할 수 있습니다([HTTP/1.1]의 11.2절). 클라이언트는 그러한 요청이 목적을 가지고 충분히 지원될 것임을 이전에 대역 내 또는 대역 외로 나타낸 오리진 서버에 직접 요청하는 경우가 아니라면 DELETE 요청에 콘텐츠를 SHOULD NOT 생성해야 합니다. 오리진 서버는 콘텐츠를 수신하기 위해 비공개 합의에 의존하지 않는 것이 SHOULD NOT 요구됩니다. HTTP 통신의 참여자는 요청 체인에 있는 중개자를 모르는 경우가 많기 때문입니다.

DELETE 메서드에 대한 응답은 캐시할 수 없습니다. 성공적인 DELETE 요청이 대상 URI에 대해 하나 이상의 저장된 응답이 있는 캐시를 통과하면 해당 저장된 응답은 무효화됩니다([CACHING]의 4.4절 참조).

CONNECT 메서드는 수신자가 요청 대상으로 식별된 대상 오리진 서버에 터널을 설정하고, 성공하면 그 이후 터널이 닫힐 때까지 양방향으로 데이터를 단순 전달하는 동작으로 제한하도록 요청합니다. 터널은 일반적으로 하나 이상의 프록시를 통해 종단 간 가상 연결을 만든 다음 TLS (전송 계층 보안, [TLS13])를 사용해 보호하는 데 사용됩니다.

CONNECT는 이 메서드에 고유한 특별한 요청 대상 형식을 사용하며, 터널 대상의 host 및 port 번호만 콜론으로 구분하여 구성합니다. 기본 port는 없습니다. CONNECT 요청이 port가 생략된 authority 구성요소를 포함하는 URI 참조를 기반으로 하더라도 클라이언트는 port 번호를 MUST 전송해야 합니다(4.1절). 예:

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

서버는 비어 있거나 유효하지 않은 port 번호를 대상으로 하는 CONNECT 요청을 MUST 거부해야 하며, 일반적으로 400 (잘못된 요청) 상태 코드로 응답합니다.

CONNECT는 HTTP 연결의 요청/응답 성격을 변경하므로 특정 HTTP 버전은 그 의미론을 프로토콜의 전송 형식에 매핑하는 방식이 다를 수 있습니다.

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

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

터널 중개자가 어느 한쪽이 연결을 닫았음을 감지하면 터널이 닫힙니다. 중개자는 닫힌 쪽에서 온 아직 전송되지 않은 모든 데이터를 다른 쪽으로 보내려고 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에 대한 2xx (성공) 응답에서 어떠한 Transfer-Encoding 또는 Content-Length 헤더 필드도 MUST NOT 전송해야 합니다. 클라이언트는 CONNECT에 대한 성공적인 응답에서 수신한 Content-Length 또는 Transfer-Encoding 헤더 필드를 MUST 무시해야 합니다.

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

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

OPTIONS 메서드는 오리진 서버 또는 개입하는 중개자에서 대상 리소스에 사용할 수 있는 통신 옵션에 관한 정보를 요청합니다. 이 메서드를 사용하면 클라이언트가 리소스 동작을 암시하지 않고 리소스와 관련된 옵션 및/또는 요구사항이나 서버의 기능을 결정할 수 있습니다.

요청 대상(7.1절)으로 별표("*")를 사용하는 OPTIONS 요청은 특정 리소스가 아닌 서버 전체에 적용됩니다. 서버의 통신 옵션은 일반적으로 리소스에 따라 달라지므로 "*" 요청은 "ping" 또는 "no-op" 유형의 메서드로만 유용합니다. 이는 클라이언트가 서버의 기능을 테스트할 수 있게 하는 것 외에는 아무 작업도 하지 않습니다. 예를 들어 프록시가 HTTP/1.1에 적합한지 여부를 테스트하는 데 사용할 수 있습니다.

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

OPTIONS에 대한 성공적인 응답을 생성하는 서버는 서버가 구현하고 대상 리소스에 적용되는 선택적 기능을 나타낼 수 있는 모든 헤더 (예: Allow)를 이 사양에서 정의하지 않은 잠재적 확장을 포함해 SHOULD 전송해야 합니다. 응답 콘텐츠가 있다면 기계 또는 사람이 읽을 수 있는 표현으로 통신 옵션을 설명할 수도 있습니다. 그러한 표현의 표준 형식은 이 사양에서 정의하지 않지만 향후 HTTP 확장에서 정의할 수 있습니다.

클라이언트는 요청 체인에서 특정 수신자를 대상으로 하기 위해 OPTIONS 요청에 Max-Forwards 헤더 필드를 MAY 전송할 수 있습니다(7.6.2절 참조). 프록시는 요청을 전달할 때 해당 요청이 Max-Forwards 필드와 함께 수신된 경우가 아니라면 Max-Forwards 헤더 필드를 MUST NOT 생성해야 합니다.

콘텐츠를 포함하는 OPTIONS 요청을 생성하는 클라이언트는 표현 미디어 유형을 설명하는 유효한 Content-Type 헤더 필드를 MUST 전송해야 합니다. 이 사양은 그러한 콘텐츠의 용도를 정의하지 않는다는 점에 유의하십시오.

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

TRACE 메서드는 요청 메시지의 원격 애플리케이션 수준 루프백을 요청합니다. 요청의 최종 수신자는 아래에 설명된 일부 필드를 제외하고 수신한 메시지를 200 (OK) 응답의 콘텐츠로 클라이언트에 되돌려 보내는 것이 SHOULD 요구됩니다. "message/http" 형식( [HTTP/1.1]의 10.1절)은 이를 수행하는 한 가지 방법입니다. 최종 수신자는 오리진 서버이거나 요청에서 0의 Max-Forwards 값을 처음 수신한 서버입니다(7.6.2절).

클라이언트는 응답에 의해 공개될 수 있는 민감한 데이터를 포함하는 필드를 TRACE 요청에 MUST NOT 생성해야 합니다. 예를 들어 사용자 에이전트가 저장된 사용자 자격 증명(11절)이나 쿠키 [COOKIE]를 TRACE 요청으로 전송하는 것은 바람직하지 않습니다. 요청의 최종 수신자는 응답 콘텐츠를 생성할 때 민감한 데이터를 포함할 가능성이 있는 모든 요청 필드를 SHOULD 제외해야 합니다.

TRACE를 사용하면 클라이언트는 요청 체인의 반대편에서 무엇이 수신되고 있는지 확인하고 해당 데이터를 테스트 또는 진단 정보에 사용할 수 있습니다. Via 헤더 필드(7.6.3절) 값은 요청 체인의 추적 역할을 하므로 특히 유용합니다. Max-Forwards 헤더 필드를 사용하면 클라이언트가 요청 체인의 길이를 제한할 수 있으며, 메시지를 무한 루프로 전달하는 프록시 체인을 테스트하는 데 유용합니다.

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

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

요청의 "Expect" 헤더 필드는 이 요청을 올바르게 처리하기 위해 서버가 지원해야 하는 특정 동작 집합 (기대 사항)을 나타냅니다.

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

Expect 필드 값은 대소문자를 구분하지 않습니다.

이 사양에서 정의하는 유일한 기대 사항은 "100-continue"입니다(정의된 매개변수 없음).

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

100-continue 기대 사항은 클라이언트가 이 요청에서 (아마 큰) 콘텐츠를 전송하려 하며, 메서드, 대상 URI 및 헤더 필드만으로 즉시 성공, 리디렉션 또는 오류 응답을 만들기에 충분하지 않다면 100 (계속) 임시 응답을 받고자 한다는 것을 수신자에게 알립니다. 이를 통해 클라이언트는 실제로 콘텐츠를 전송하기 전에 전송할 가치가 있다는 표시를 기다릴 수 있으므로 데이터가 매우 크거나 클라이언트가 오류가 발생할 가능성이 높다고 예상할 때 효율성을 높일 수 있습니다(예: 이전에 검증한 인증 자격 증명 없이 처음으로 상태 변경 메서드를 전송하는 경우).

예를 들어 다음으로 시작하는 요청은

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

클라이언트가 불필요한 데이터 전송으로 연결을 채우기 시작하기 전에 오리진 서버가 401 (인증되지 않음) 또는 405 (허용되지 않는 메서드)와 같은 오류 메시지로 즉시 응답할 수 있게 합니다.

• 클라이언트는 콘텐츠를 포함하지 않는 요청에 100-continue 기대 사항을 MUST NOT 생성해야 합니다.
• 요청 콘텐츠를 전송하기 전에 100 (계속) 응답을 기다릴 클라이언트는 100-continue 기대 사항을 포함하는 Expect 헤더 필드를 MUST 전송해야 합니다.
• 100-continue 기대 사항을 전송하는 클라이언트는 특정 시간만큼 기다릴 필요가 없습니다. 그러한 클라이언트는 아직 응답을 받지 못했더라도 콘텐츠 전송을 MAY 진행할 수 있습니다. 또한 100 (계속) 응답은 HTTP/1.0 중개자를 통과해 전송될 수 없으므로 그러한 클라이언트는 콘텐츠를 전송하기 전에 무기한 기다리지 않는 것이 SHOULD NOT 요구됩니다.
• 100-continue 기대 사항을 포함한 요청에 대한 응답으로 417 (기대 조건 실패) 상태 코드를 수신한 클라이언트는 100-continue 기대 사항 없이 해당 요청을 SHOULD 반복해야 합니다. 417 응답은 응답 체인이 기대 사항을 지원하지 않음을 나타낼 뿐이기 때문입니다(예: HTTP/1.0 서버를 통과함).

• HTTP/1.0 요청에서 100-continue 기대 사항을 수신한 서버는 해당 기대 사항을 MUST 무시해야 합니다.
• 서버가 대응하는 요청의 콘텐츠 일부 또는 전부를 이미 수신했거나 프레이밍이 콘텐츠가 없음을 나타낸다면 100 (계속) 응답 전송을 MAY 생략할 수 있습니다.
• 100 (계속) 응답을 전송하는 서버는 연결이 조기에 닫히지 않는 한 요청 콘텐츠를 수신하고 처리한 후 최종 상태 코드를 MUST 전송해야 합니다.
• 전체 요청 콘텐츠를 읽기 전에 최종 상태 코드로 응답하는 서버는 연결을 닫을지([HTTP/1.1]의 9.6절 참조) 또는 요청 콘텐츠를 계속 읽을지 SHOULD 나타내야 합니다.

• 메서드, 대상 URI 및 헤더 필드만 검사하여 해당 상태를 결정할 수 있다면 최종 상태 코드가 있는 즉시 응답, 또는
• 클라이언트가 요청 콘텐츠를 전송하도록 유도하는 즉시 100 (계속) 응답

오리진 서버는 100 (계속) 응답을 전송하기 전에 콘텐츠를 기다려서는 MUST NOT 됩니다.

• 메서드, 대상 URI 및 헤더 필드만 검사하여 해당 상태를 결정할 수 있다면 최종 상태 코드가 있는 즉시 응답을 전송하거나,
• 대응하는 요청 라인과 헤더 섹션을 다음 인바운드 서버에 전송하여 요청을 오리진 서버 방향으로 전달합니다.

프록시가 구성이나 과거 상호작용을 통해 다음 인바운드 서버가 HTTP/1.0만 지원한다고 판단하면, 프록시는 클라이언트가 콘텐츠 전송을 시작하도록 유도하기 위해 즉시 100 (계속) 응답을 MAY 생성할 수 있습니다.

  From    = mailbox

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

From: spider-admin@example.org

From 헤더 필드는 로봇이 아닌 사용자 에이전트가 전송하는 경우가 드뭅니다. 사용자 에이전트는 사용자가 명시적으로 구성하지 않은 경우 From 헤더 필드를 SHOULD NOT 전송해야 합니다. 이는 사용자의 개인정보 보호 이익이나 사이트의 보안 정책과 충돌할 수 있기 때문입니다.

로봇 사용자 에이전트는 과도하거나 원하지 않거나 유효하지 않은 요청을 로봇이 전송하는 경우처럼 서버에 문제가 발생했을 때 로봇 운영 책임자에게 연락할 수 있도록 유효한 From 헤더 필드를 SHOULD 전송해야 합니다.

서버는 접근 제어 또는 인증에 From 헤더 필드를 SHOULD NOT 사용해야 합니다. 그 값은 요청을 수신하거나 관찰하는 누구에게나 표시될 것으로 예상되며 개인정보 보호에 대한 기대 없이 로그 파일과 오류 보고서에 기록되는 경우가 많기 때문입니다.

"Referer" [sic] 헤더 필드를 사용하면 사용자 에이전트가 대상 URI를 얻은 리소스의 URI 참조를 지정할 수 있습니다 (즉, "referrer"이지만 필드 이름의 철자가 잘못됨). 사용자 에이전트는 Referer 필드 값을 생성할 때 URI 참조의 프래그먼트 및 userinfo 구성요소가 있다면 이를 MUST NOT 포함해야 합니다 [URI].

  Referer = absolute-URI / partial-URI

필드 값은 absolute-URI 또는 partial-URI입니다. 후자의 경우(4절) 참조되는 URI는 대상 URI를 기준으로 합니다([URI], 5절).

Referer 헤더 필드를 사용하면 서버가 간단한 분석, 로깅, 최적화된 캐싱 등을 위해 다른 리소스로 돌아가는 링크를 생성할 수 있습니다. 또한 오래되거나 잘못 입력된 링크를 유지 관리 목적으로 찾을 수 있습니다. 일부 서버는 Referer 헤더 필드를 다른 사이트의 링크(이른바 "딥 링크")를 거부하거나 사이트 간 요청 위조(CSRF)를 제한하는 수단으로 사용하지만 모든 요청에 이 필드가 있는 것은 아닙니다.

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

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

Referer 헤더 필드 값은 참조하는 리소스의 전체 URI를 전달할 필요가 없습니다. 사용자 에이전트는 참조 오리진 이외의 부분을 MAY 잘라낼 수 있습니다.

Referer 헤더 필드는 요청 컨텍스트 또는 사용자의 탐색 기록에 관한 정보를 드러낼 가능성이 있습니다. 참조하는 리소스의 식별자가 개인 정보(예: 계정 이름)나 기밀이어야 하는 리소스(예: 방화벽 뒤 또는 보호된 서비스 내부)를 드러낸다면 이는 개인정보 보호 문제입니다. 대부분의 범용 사용자 에이전트는 참조 리소스가 로컬 "file" 또는 "data" URI인 경우 Referer 헤더 필드를 전송하지 않습니다. 참조 리소스가 보안 프로토콜을 통해 접근되었고 요청 대상의 오리진이 참조 리소스의 오리진과 다르면, 참조 리소스가 Referer 전송을 명시적으로 허용하지 않는 한 사용자 에이전트는 Referer 헤더 필드를 SHOULD NOT 전송해야 합니다. 참조 리소스가 보안 프로토콜을 통해 접근되었다면 사용자 에이전트는 보호되지 않은 HTTP 요청에 Referer 헤더 필드를 MUST NOT 전송해야 합니다. 추가 보안 고려사항은 17.9절을 참조하십시오.

일부 중개자는 발신 요청에서 Referer 헤더 필드를 무차별적으로 제거하는 것으로 알려져 있습니다. 이는 사용자에게 훨씬 더 큰 피해를 줄 수 있는 CSRF 공격에 대한 보호를 방해하는 바람직하지 않은 부작용을 일으킵니다. Referer에서 정보 공개를 제한하려는 중개자 및 사용자 에이전트 확장은 내부 도메인 이름을 가명으로 대체하거나 query 및/또는 path 구성요소를 잘라내는 것과 같은 특정 편집으로 변경을 제한하는 것이 바람직합니다. 필드 값이 대상 URI와 동일한 scheme 및 host를 공유하는 경우 중개자는 Referer 헤더 필드를 SHOULD NOT 수정하거나 삭제해야 합니다.

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

6.5절에 설명된 대로 요청에서 전송된 "trailers" 멤버를 가진 TE 필드는 클라이언트가 트레일러 필드를 버리지 않음을 나타냅니다.

TE는 HTTP/1.1에서 클라이언트가 응답에서 수락할 수 있는 전송 코딩을 서버에 알리는 데도 사용됩니다. 이 문서가 게시된 시점에는 HTTP/1.1만 전송 코딩을 사용합니다([HTTP/1.1]의 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 헤더 필드(7.6.1절) 안에 "TE" 연결 옵션도 MUST 전송해야 합니다.

"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 필드 값은 요청 지연 시간과 사용자가 원하지 않는데도 식별될 위험("핑거프린팅")을 증가시킵니다.

마찬가지로 구현은 다른 구현과의 호환성을 선언하기 위해 다른 구현의 제품 토큰을 사용하지 않는 것이 권장됩니다. 이는 필드의 목적을 우회하기 때문입니다. 사용자 에이전트가 다른 사용자 에이전트로 가장하는 경우 실제 사용 중인 사용자 에이전트에서 제대로 작동하지 않을 수 있더라도 수신자는 사용자가 해당 식별된 사용자 에이전트에 맞춘 응답을 의도적으로 보기를 원한다고 가정할 수 있습니다.

"Allow" 헤더 필드는 대상 리소스가 지원한다고 알리는 메서드 집합을 나열합니다. 이 필드의 목적은 리소스와 관련된 유효한 요청 메서드를 수신자에게 알리는 것으로 엄격히 제한됩니다.

  Allow = #method

Allow: GET, HEAD, PUT

실제로 허용되는 메서드 집합은 각 요청 시점에 오리진 서버가 정의합니다. 오리진 서버는 405 (허용되지 않는 메서드) 응답에 Allow 헤더 필드를 MUST 생성해야 하며, 다른 모든 응답에서도 그렇게 MAY 할 수 있습니다. 빈 Allow 필드 값은 리소스가 어떠한 메서드도 허용하지 않음을 나타내며, 구성에 의해 리소스가 일시적으로 비활성화된 경우 405 응답에서 발생할 수 있습니다.

프록시는 Allow 헤더 필드를 MUST NOT 수정해야 합니다. 일반적인 메시지 처리 규칙에 따라 처리하기 위해 표시된 모든 메서드를 이해할 필요가 없기 때문입니다.

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

  Location = URI-reference

필드 값은 하나의 URI-reference로 구성됩니다. 상대 참조 형식([URI], 4.2절)인 경우 최종 값은 대상 URI를 기준으로 해석하여 계산됩니다([URI], 5절).

201 (생성됨) 응답에서 Location 값은 요청에 의해 생성된 주 리소스를 참조합니다. 3xx (리디렉션) 응답에서 Location 값은 요청을 자동으로 리디렉션하기 위한 선호 대상 리소스를 참조합니다.

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

Location: /People.html#tim

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

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

이는 원래 프래그먼트 식별자를 유지하면서 사용자 에이전트가 "http://www.example.net/index.html#larry"로 리디렉션할 것을 제안합니다.

Location 값의 프래그먼트 식별자가 적절하지 않은 경우도 있습니다. 예를 들어 201 (생성됨) 응답의 Location 헤더 필드는 생성된 리소스에 특화된 URI를 제공하도록 되어 있습니다.

서버는 사용자 에이전트가 후속 요청을 하기 전에 얼마나 기다리는 것이 바람직한지를 나타내기 위해 "Retry-After" 헤더 필드를 전송합니다. 503 (서비스 사용 불가) 응답과 함께 전송된 경우 Retry-After는 클라이언트에게 서비스가 사용할 수 없을 것으로 예상되는 기간을 나타냅니다. 모든 3xx (리디렉션) 응답과 함께 전송된 경우 Retry-After는 사용자 에이전트가 리디렉션된 요청을 보내기 전에 기다리도록 요청받는 최소 시간을 나타냅니다.

Retry-After 필드 값은 HTTP-date 또는 응답을 수신한 후 지연할 초 단위 시간일 수 있습니다.

  Retry-After = HTTP-date / delay-seconds

delay-seconds 값은 초 단위 시간을 나타내는 음이 아닌 십진 정수입니다.

  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 (인증되지 않음) 응답을 생성하는 서버는 하나 이상의 챌린지를 포함하는 WWW-Authenticate 헤더 필드를 MUST 전송해야 합니다. 서버는 자격 증명(또는 다른 자격 증명)을 제공하면 응답에 영향을 줄 수 있음을 나타내기 위해 다른 응답 메시지에 WWW-Authenticate 헤더 필드를 MAY 생성할 수 있습니다.

응답을 전달하는 프록시는 해당 응답의 어떠한 WWW-Authenticate 헤더 필드도 MUST NOT 수정해야 합니다.

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

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

이 헤더 필드에는 두 개의 챌린지가 있습니다. 하나는 realm 값이 "simple"인 "Basic" 스킴이고 다른 하나는 realm 값이 "apps"인 "Newauth" 스킴입니다. 또한 "type" 및 "title"이라는 두 개의 추가 매개변수를 포함합니다.

그러나 일부 사용자 에이전트는 이 형식을 인식하지 못합니다. 따라서 동일한 필드 라인에 둘 이상의 멤버가 있는 WWW-Authenticate 필드 값을 전송하면 상호운용되지 않을 수 있습니다.

"Authorization" 헤더 필드를 사용하면 사용자 에이전트가 오리진 서버에 자신을 인증할 수 있습니다. 일반적으로, 하지만 반드시 그런 것은 아니며, 401 (인증되지 않음) 응답을 수신한 후입니다. 그 값은 요청 중인 리소스의 realm에 대한 사용자 에이전트의 인증 정보를 포함하는 자격 증명으로 구성됩니다.

  Authorization = credentials

요청이 인증되고 realm이 지정되면 인증 스킴 자체가 다른 것을 요구하지 않는다고 가정할 때(예: 챌린지 값에 따라 달라지는 자격 증명 또는 동기화된 시계 사용), 동일한 자격 증명은 이 realm 내의 다른 모든 요청에도 유효한 것으로 간주됩니다.

요청을 전달하는 프록시는 해당 요청의 어떠한 Authorization 헤더 필드도 MUST NOT 수정하지 마십시오. HTTP 캐시의 Authorization 헤더 필드 처리에 관한 세부 사항과 요구사항은 [CACHING]의 3.5절을 참조하십시오.

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-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-Authenticate 헤더 필드를 사용하여 인증을 요구한 다음 인바운드 프록시에만 적용됩니다. 체인에서 여러 프록시를 사용하는 경우 Proxy-Authorization 헤더 필드는 자격 증명을 받을 것으로 예상한 첫 번째 인바운드 프록시가 소비합니다. 프록시는 프록시들이 특정 요청을 협력하여 인증하는 메커니즘인 경우 클라이언트 요청의 자격 증명을 다음 프록시로 MAY 중계할 수 있습니다.

  Proxy-Authentication-Info = #auth-param

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

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

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

콘텐츠 협상 헤더 필드가 요청에 있고 응답에 사용 가능한 표현 중 해당 필드에 따라 허용 가능하다고 간주할 수 있는 것이 없다면 오리진 서버는 406 (허용할 수 없음) 응답을 전송하여 헤더 필드를 준수하거나, 응답이 해당 요청 헤더 필드에 대한 콘텐츠 협상의 대상이 아닌 것처럼 처리하여 헤더 필드를 무시할 수 있습니다. 그러나 그렇다고 해서 클라이언트가 해당 표현을 사용할 수 있다는 의미는 아닙니다.

이 사양에서 정의하는 콘텐츠 협상 필드는 관련 콘텐츠 종류에 대한 선호에 상대적인 "가중치"를 지정하기 위해 "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에서 와일드카드 값은 변형이 무제한임을 의미합니다.

"Accept" 헤더 필드는 사용자 에이전트가 응답 미디어 유형에 대한 기본 설정을 지정하는 데 사용할 수 있습니다. 예를 들어 Accept 헤더 필드를 사용하여 인라인 이미지 요청의 경우처럼 요청이 원하는 소수의 유형으로 특별히 제한됨을 나타낼 수 있습니다.

서버가 응답에서 전송하는 경우 Accept는 동일한 리소스에 대한 후속 요청의 콘텐츠에서 어떤 콘텐츠 유형이 선호되는지에 관한 정보를 제공합니다.

  Accept = #( media-range [ weight ] )

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

별표 "*" 문자는 미디어 유형을 범위로 그룹화하는 데 사용되며, "*/*"는 모든 미디어 유형을 나타내고 "type/*"는 해당 유형의 모든 subtype을 나타냅니다. media-range에는 해당 범위에 적용되는 미디어 유형 매개변수가 포함될 수 있습니다.

각 media-range 뒤에는 선택적 적용 가능한 미디어 유형 매개변수 (예: charset)가 올 수 있고, 그 뒤에는 상대적 가중치를 나타내기 위한 선택적 "q" 매개변수(12.4.2절)가 올 수 있습니다.

이전 사양에서는 가중치 매개변수 뒤에 추가 확장 매개변수가 나타나는 것을 허용했습니다. accept 확장 문법(accept-params, accept-ext)은 정의가 복잡했고 실제로 사용되지 않았으며 새 헤더 필드를 통해 더 쉽게 배포할 수 있으므로 제거되었습니다. 가중치를 사용하는 송신자는 "q"를 마지막에(모든 media-range 매개변수 뒤에) SHOULD 전송해야 합니다. 수신자는 매개변수 순서와 관계없이 "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 표현을 보내라"는 의미입니다.

미디어 범위는 더 구체적인 미디어 범위 또는 특정 미디어 유형으로 재정의할 수 있습니다. 주어진 유형에 둘 이상의 미디어 범위가 적용되면 가장 구체적인 참조가 우선합니다. 예:

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

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

주어진 유형과 관련된 미디어 유형 품질 계수는 해당 유형과 일치하는 가장 높은 우선순위의 미디어 범위를 찾아 결정합니다. 예:

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에 대한 기본 설정을 나타내기 위해 전송할 수 있습니다. 예를 들어 이 필드를 사용하면 더 포괄적이거나 특수 목적의 charset을 이해할 수 있는 사용자 에이전트가 그러한 charset으로 정보를 표현할 수 있는 오리진 서버에 해당 기능을 알릴 수 있습니다.

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

Charset 이름은 8.3.2절에 정의되어 있습니다. 사용자 에이전트는 12.4.2절에 정의된 대로 각 charset에 사용자의 상대적 선호도를 나타내는 품질 값을 MAY 연결할 수 있습니다. 예:

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

Accept-Charset 헤더 필드에 특수 값 "*"가 있으면 필드의 다른 곳에서 언급되지 않은 모든 charset과 일치합니다.

"Accept-Encoding" 헤더 필드는 콘텐츠 코딩(8.4.1절) 사용에 대한 기본 설정을 나타내는 데 사용할 수 있습니다.

사용자 에이전트가 요청에서 전송하는 경우 Accept-Encoding은 응답에서 허용 가능한 콘텐츠 코딩을 나타냅니다.

서버가 응답에서 전송하는 경우 Accept-Encoding은 동일한 리소스에 대한 후속 요청의 콘텐츠에서 어떤 콘텐츠 코딩이 선호되는지에 관한 정보를 제공합니다.

인코딩하지 않는 것이 선호되는 경우를 전달하기 위해 "identity" 토큰을 "인코딩 없음"의 동의어로 사용합니다.

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

각 codings 값에는 12.4.2절에 정의된 대로 해당 인코딩에 대한 선호도를 나타내는 관련 품질 값 (가중치)을 MAY 지정할 수 있습니다. 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" 또는 "identity"에 대한 더 구체적인 항목이 없는 "*;q=0"을 명시하여 특별히 제외하지 않는 한 기본적으로 허용 가능합니다.
3. 표현의 콘텐츠 코딩이 Accept-Encoding 필드 값에 나열된 콘텐츠 코딩 중 하나라면 qvalue 0이 함께 지정되지 않은 한 허용 가능합니다. (12.4.2절에 정의된 대로 qvalue 0은 "허용할 수 없음"을 의미합니다.)

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

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

Accept-Encoding 헤더 필드가 응답에 있으면 해당 요청에서 리소스가 어떤 콘텐츠 코딩을 허용할 의향이 있었는지를 나타냅니다. 필드 값은 요청에서와 동일한 방식으로 평가됩니다.

이 정보는 관련 요청에만 해당한다는 점에 유의하십시오. 지원되는 인코딩 집합은 동일한 서버의 다른 리소스에서 다를 수 있으며 시간이 지나면서 변경되거나 요청의 다른 측면(예: 요청 메서드)에 따라 달라질 수 있습니다.

지원되지 않는 콘텐츠 코딩으로 인해 요청이 실패한 서버는 415 (지원되지 않는 미디어 유형) 상태로 응답하고 해당 응답에 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절에서는 여러 일치 방식을 정의합니다. 구현은 요구사항에 가장 적절한 일치 방식을 제공할 수 있습니다. "기본 필터링" 방식([RFC4647], 3.3.1절)은 이전에 [RFC2616]의 14.4절에서 HTTP에 대해 정의된 일치 방식과 동일합니다.

모든 요청에서 사용자의 전체 언어 기본 설정을 포함하는 Accept-Language 헤더 필드를 전송하면 사용자의 개인정보 보호 기대에 반할 수 있습니다 (17.13절).

이해 가능성은 개별 사용자에게 크게 의존하므로 사용자 에이전트는 언어 기본 설정을 사용자가 제어할 수 있도록 해야 합니다(사용자 에이전트 자체의 구성을 통하거나 사용자가 제어할 수 있는 시스템 설정을 기본값으로 사용). 그러한 제어를 사용자에게 제공하지 않는 사용자 에이전트는 Accept-Language 헤더 필드를 MUST NOT 전송해야 합니다.

응답의 "Vary" 헤더 필드는 메서드와 대상 URI를 제외하고 요청 메시지의 어떤 부분이 오리진 서버가 이 응답의 콘텐츠를 선택하는 과정에 영향을 주었을 수 있는지 설명합니다.

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

Vary 필드 값은 와일드카드 멤버 "*" 또는 이 응답의 표현을 선택하는 데 역할을 했을 수 있는 요청 필드 이름의 목록이며, 이를 선택 헤더 필드라고 합니다. 가능한 선택 헤더 필드는 이 사양에서 정의된 필드로 제한되지 않습니다.

멤버 "*"를 포함하는 목록은 요청의 다른 측면이 응답 표현을 선택하는 데 역할을 했을 수 있음을 나타내며, 메시지 구문 밖의 측면 (예: 클라이언트의 네트워크 주소)도 포함될 수 있습니다. 수신자는 요청을 오리진 서버에 전달하지 않고는 이 응답이 이후 요청에 적합한지 결정할 수 없습니다. 프록시는 Vary 필드 값에 "*"를 MUST NOT 생성해야 합니다.

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

Vary: accept-encoding, accept-language

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

1. 이후 요청이 원래 요청과 나열된 헤더 필드에 대해 동일한 값을 갖지 않는 한 캐시 수신자가 이 응답을 이후 요청을 충족하는 데 MUST NOT 사용해야 함을 알립니다( [CACHING]의 4.1절) 또는 응답 재사용이 오리진 서버에 의해 검증되어야 합니다. 즉 Vary는 새 요청을 저장된 캐시 항목과 일치시키는 데 필요한 캐시 키를 확장합니다.

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

오리진 서버는 캐시 가능한 응답을 후속 요청에 선택적으로 재사용하기를 원하는 경우 해당 응답에 Vary 헤더 필드를 SHOULD 생성해야 합니다. 일반적으로 오리진 서버가 요청의 Accept-Language 헤더 필드를 바탕으로 응답 언어를 선택한 경우처럼, 응답 콘텐츠가 선택 헤더 필드로 표현된 기본 설정에 더 잘 맞도록 조정된 경우가 이에 해당합니다.

특히 캐시 응답 지시어([CACHING]의 5.2절)에 의해 재사용이 이미 제한된 경우 오리진 서버가 콘텐츠 선택의 변형보다 캐싱에 대한 Vary의 성능 영향을 더 중요하게 여긴다면 Vary를 생략할 수 있습니다.

다른 사용자에 대한 해당 응답의 재사용은 필드 정의(11.6.2절)에서 금지하므로 Vary에 Authorization 필드 이름을 전송할 필요가 없습니다. 마찬가지로 응답 콘텐츠가 네트워크 지역에 따라 선택되거나 영향을 받았지만 오리진 서버가 수신자가 한 지역에서 다른 지역으로 이동하더라도 캐시된 응답이 재사용되기를 원한다면 오리진 서버는 그러한 변형을 Vary에 나타낼 필요가 없습니다.

"If-Match" 헤더 필드는 필드 값이 "*"인 경우 수신 오리진 서버가 대상 리소스의 현재 표현을 하나 이상 가지고 있거나, 필드 값에 제공된 엔터티 태그 목록의 멤버와 일치하는 엔터티 태그를 가진 대상 리소스의 현재 표현을 가지고 있는 것을 조건으로 요청 메서드를 실행하도록 합니다.

클라이언트는 표현 데이터에 어떠한 변경이라도 있었다면 메서드가 적용되지 않도록 이 사전 조건을 의도하므로, 오리진 서버는 If-Match의 엔터티 태그를 비교할 때 강한 비교 함수를 MUST 사용해야 합니다(8.8.3.2절).

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

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

If-Match는 여러 사용자 에이전트가 동일한 리소스에서 병렬로 동작할 수 있을 때 우발적인 덮어쓰기를 방지하기 위해(즉, "업데이트 손실" 문제를 방지하기 위해) 상태 변경 메서드(예: POST, PUT, DELETE)와 함께 가장 자주 사용됩니다. 일반적으로 표현의 선택 또는 수정과 관련된 모든 메서드에서 선택된 표현의 현재 엔터티 태그가 If-Match 필드 값 안의 멤버가 아닌 경우 요청을 중단하는 데 사용할 수 있습니다.

오리진 서버가 표현을 선택하는 요청을 수신하고 해당 요청에 If-Match 헤더 필드가 포함되어 있으면 오리진 서버는 메서드를 수행하기 전에 13.2절에 따라 If-Match 조건을 MUST 평가해야 합니다.

1. 필드 값이 "*"이면 오리진 서버가 대상 리소스의 현재 표현을 가지고 있는 경우 조건은 true입니다.
2. 필드 값이 엔터티 태그 목록이면 나열된 태그 중 하나가 선택된 표현의 엔터티 태그와 일치하는 경우 조건은 true입니다.
3. 그렇지 않으면 조건은 false입니다.

If-Match 조건을 평가하는 오리진 서버는 조건이 false로 평가되면 요청된 메서드를 MUST NOT 수행해야 합니다. 대신 오리진 서버는 412 (사전 조건 실패) 상태 코드로 응답하여 조건부 요청이 실패했음을 MAY 나타낼 수 있습니다. 또는 요청이 선택된 표현에 이미 적용된 것으로 보이는 상태 변경 작업이라면 오리진 서버는 2xx (성공) 상태 코드로 MAY 응답할 수 있습니다(즉, 사용자 에이전트가 요청한 변경은 이미 성공했지만 사용자 에이전트가 이를 알지 못할 수 있으며, 이전 응답이 손실되었거나 다른 사용자 에이전트가 동등한 변경을 수행했을 수 있음).

변경 요청이 이미 적용된 것으로 보이는 경우 오리진 서버가 성공 응답을 전송할 수 있도록 허용하는 것은 많은 작성 사용 사례에서 더 효율적이지만, 여러 사용자 에이전트가 매우 유사하지만 협력하지 않는 변경 요청을 수행하는 경우 어느 정도 위험이 있습니다. 예를 들어 여러 사용자 에이전트가 공통 리소스를 세마포어로 사용해 쓰는 경우(예: 비원자적 증가) 충돌하여 중요한 상태 전환을 잃을 가능성이 높습니다. 그러한 종류의 리소스에서는 오리진 서버가 안전하지 않은 메서드의 실패한 모든 사전 조건에 엄격하게 412를 전송하는 것이 더 좋습니다. 다른 경우에는 성공 응답에서 ETag 필드를 제외하면 사용자 에이전트가 다음 요청으로 GET을 수행하여 리소스의 현재 상태에 대한 혼란을 없애도록 유도할 수 있습니다.

클라이언트는 선택된 표현이 일치하지 않는 경우 412 (사전 조건 실패) 응답을 선호한다는 것을 나타내기 위해 GET 요청에 If-Match 헤더 필드를 MAY 전송할 수 있습니다. 그러나 이는 새 표현을 원하지 않으면서 이전에 수신한 부분 표현을 완료하기 위한 범위 요청(14절)에서만 유용합니다. 클라이언트가 새 표현을 받기를 선호하는 범위 요청에는 If-Range(13.1.5절)가 더 적합합니다.

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

"*"와 다른 값("*"의 다른 인스턴스 포함)을 포함하는 목록 값을 가진 If-Match 헤더 필드는 구문상 유효하지 않으며(따라서 생성할 수 없음) 또한 상호운용 가능성이 낮다는 점에 유의하십시오.

"If-None-Match" 헤더 필드는 필드 값이 "*"인 경우 수신 캐시 또는 오리진 서버에 대상 리소스의 현재 표현이 전혀 없거나, 필드 값에 나열된 어떠한 엔터티 태그와도 일치하지 않는 엔터티 태그를 가진 선택된 표현이 있는 것을 조건으로 요청 메서드를 실행하도록 합니다.

표현 데이터에 변경이 있었더라도 약한 엔터티 태그를 캐시 검증에 사용할 수 있으므로 수신자는 If-None-Match의 엔터티 태그를 비교할 때 약한 비교 함수를 MUST 사용해야 합니다(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 (수정되지 않음) 응답을 전송할 수 있습니다.

If-None-Match는 클라이언트가 리소스에 현재 표현이 없다고 믿을 때 안전하지 않은 요청 메서드(예: PUT)가 대상 리소스의 기존 표현을 실수로 수정하지 못하도록 "*" 값과 함께 사용할 수도 있습니다(9.2.1절). 이는 둘 이상의 클라이언트가 대상 리소스의 초기 표현을 생성하려고 시도할 경우 발생할 수 있는 "업데이트 손실" 문제의 변형입니다.

오리진 서버가 표현을 선택하는 요청을 수신하고 해당 요청에 If-None-Match 헤더 필드가 포함되어 있으면 오리진 서버는 메서드를 수행하기 전에 13.2절에 따라 If-None-Match 조건을 MUST 평가해야 합니다.

1. 필드 값이 "*"이면 오리진 서버가 대상 리소스의 현재 표현을 가지고 있는 경우 조건은 false입니다.
2. 필드 값이 엔터티 태그 목록이면 나열된 태그 중 하나가 선택된 표현의 엔터티 태그와 일치하는 경우 조건은 false입니다.
3. 그렇지 않으면 조건은 true입니다.

If-None-Match 조건을 평가하는 오리진 서버는 조건이 false로 평가되면 요청된 메서드를 MUST NOT 수행해야 합니다. 대신 오리진 서버는 요청 메서드가 GET 또는 HEAD인 경우 a) 304 (수정되지 않음) 상태 코드 또는 그 밖의 모든 요청 메서드의 경우 b) 412 (사전 조건 실패) 상태 코드 중 하나로 MUST 응답해야 합니다.

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

"*"와 다른 값("*"의 다른 인스턴스 포함)을 포함하는 목록 값을 가진 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를 구현하지 않을 수 있는 이전 중개자와의 상호운용을 위해서만 함께 사용됩니다.

수신한 필드 값이 유효한 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 헤더 필드가 포함되어 있으면 오리진 서버는 메서드를 수행하기 전에 13.2절에 따라 If-Modified-Since 조건을 SHOULD 평가해야 합니다.

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

If-Modified-Since 조건을 평가하는 오리진 서버는 조건이 false로 평가되면 요청된 메서드를 SHOULD NOT 수행해야 합니다. 대신 오리진 서버는 이전에 캐시된 응답을 식별하거나 갱신하는 데 유용한 메타데이터만 포함하여 304 (수정되지 않음) 응답을 SHOULD 생성해야 합니다.

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

"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를 구현하지 않을 수 있는 이전 중개자와의 상호운용을 위해서만 함께 사용됩니다.

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

리소스에 사용 가능한 수정 날짜가 없으면 수신자는 If-Unmodified-Since 헤더 필드를 MUST 무시해야 합니다.

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

If-Unmodified-Since는 여러 사용자 에이전트가 엔터티 태그를 제공하지 않는 표현을 가진 리소스에서 병렬로 동작할 수 있을 때 우발적인 덮어쓰기를 방지하기 위해(즉, "업데이트 손실" 문제를 방지하기 위해) 상태 변경 메서드(예: POST, PUT, DELETE)와 함께 가장 자주 사용됩니다. 일반적으로 표현의 선택 또는 수정과 관련된 모든 메서드에서 선택된 표현의 마지막 수정 날짜가 If-Unmodified-Since 필드 값에 제공된 날짜 이후 변경된 경우 요청을 중단하는 데 사용할 수 있습니다.

오리진 서버가 표현을 선택하는 요청을 수신하고 해당 요청에 If-Match 헤더 필드 없이 If-Unmodified-Since 헤더 필드가 포함되어 있으면 오리진 서버는 메서드를 수행하기 전에 13.2절에 따라 If-Unmodified-Since 조건을 MUST 평가해야 합니다.

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

If-Unmodified-Since 조건을 평가하는 오리진 서버는 조건이 false로 평가되면 요청된 메서드를 MUST NOT 수행해야 합니다. 대신 오리진 서버는 412 (사전 조건 실패) 상태 코드로 응답하여 조건부 요청이 실패했음을 MAY 나타낼 수 있습니다. 또는 요청이 선택된 표현에 이미 적용된 것으로 보이는 상태 변경 작업이라면 오리진 서버는 2xx (성공) 상태 코드로 MAY 응답할 수 있습니다(즉, 사용자 에이전트가 요청한 변경은 이미 성공했지만 사용자 에이전트가 이를 알지 못할 수 있으며, 이전 응답이 손실되었거나 다른 사용자 에이전트가 동등한 변경을 수행했을 수 있음).

변경 요청이 이미 적용된 것으로 보이는 경우 오리진 서버가 성공 응답을 전송할 수 있도록 허용하는 것은 많은 작성 사용 사례에서 더 효율적이지만, 여러 사용자 에이전트가 매우 유사하지만 협력하지 않는 변경 요청을 수행하는 경우 어느 정도 위험이 있습니다. 그러한 경우 오리진 서버는 안전하지 않은 메서드의 실패한 모든 사전 조건에 엄격하게 412를 전송하는 것이 더 좋습니다.

클라이언트는 선택된 표현이 수정된 경우 412 (사전 조건 실패) 응답을 선호한다는 것을 나타내기 위해 GET 요청에 If-Unmodified-Since 헤더 필드를 MAY 전송할 수 있습니다. 그러나 이는 새 표현을 원하지 않으면서 이전에 수신한 부분 표현을 완료하기 위한 범위 요청(14절)에서만 유용합니다. 클라이언트가 새 표현을 받기를 선호하는 범위 요청에는 If-Range(13.1.5절)가 더 적합합니다.

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

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

클라이언트가 표현의 부분 사본을 가지고 있고 전체 표현의 최신 사본을 원한다면 조건부 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 생성해야 합니다. 클라이언트는 대응하는 표현에 대한 엔터티 태그가 없고 날짜가 8.8.2.2절에서 정의한 의미의 강한 검증자인 경우가 아니라면 HTTP-date를 포함하는 If-Range 헤더 필드를 MUST NOT 생성해야 합니다.

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

1. 제공된 HTTP-date 검증자가 8.8.2.2절에서 정의한 의미의 강한 검증자가 아니면 조건은 false입니다.
2. 제공된 HTTP-date 검증자가 선택된 표현의 Last-Modified 필드 값과 정확히 일치하면 조건은 true입니다.
3. 그렇지 않으면 조건은 false입니다.

1. 제공된 entity-tag 검증자가 강한 비교 함수(8.8.3.2절)를 사용하여 선택된 표현의 ETag 필드 값과 정확히 일치하면 조건은 true입니다.
2. 그렇지 않으면 조건은 false입니다.

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

If-Range 비교는 검증자가 HTTP-date인 경우를 포함해 정확히 일치하는지를 비교하므로 If-Unmodified-Since 조건을 평가할 때 사용하는 "이전이거나 같음" 비교와 다르다는 점에 유의하십시오.

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

대상 리소스의 오리진 서버가 아니며 대상 리소스에 대한 요청의 캐시 역할을 할 수 없는 서버는 이 사양에서 정의한 조건부 요청 헤더 필드를 MUST NOT 평가해야 하며, 요청을 전달한다면 이를 MUST 전달해야 합니다. 생성한 클라이언트는 현재 표현을 제공할 수 있는 서버가 이를 평가하도록 의도하기 때문입니다. 마찬가지로 서버는 CONNECT, OPTIONS 또는 TRACE처럼 선택된 표현의 선택 또는 수정과 관련되지 않는 요청 메서드와 함께 수신된 경우 이 사양에서 정의한 조건부 요청 헤더 필드를 MUST 무시해야 합니다.

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

조건부 요청 헤더 필드는 HEAD의 의미론을 GET과 일관되게 유지하기 위해 HEAD 메서드와 함께 사용할 수 있는 것으로 정의되어 있지만, 성공적인 응답은 304 (수정되지 않음) 응답과 거의 같은 크기이고 412 (사전 조건 실패) 응답보다 더 유용하므로 조건부 HEAD를 전송할 의미는 없습니다.

요청에 둘 이상의 조건부 요청 헤더 필드가 있으면 필드를 평가하는 순서가 중요해집니다. 실제로 이 문서에 정의된 필드는 일관되게 하나의 논리적 순서로 구현됩니다. "업데이트 손실" 사전 조건은 캐시 검증보다 더 엄격한 요구사항을 가지며, 검증된 캐시는 부분 응답보다 더 효율적이고, 엔터티 태그는 날짜 검증자보다 더 정확한 것으로 간주되기 때문입니다.

1. 수신자가 오리진 서버이고 If-Match가 있으면 If-Match 사전 조건을 평가합니다.

   • true이면 3단계로 계속합니다.
   • false이면 상태 변경 요청이 이미 성공했음을 확인할 수 있는 경우가 아니라면 412 (사전 조건 실패)로 응답합니다(13.1.1절 참조).

2. 수신자가 오리진 서버이고 If-Match가 없으며 If-Unmodified-Since가 있으면 If-Unmodified-Since 사전 조건을 평가합니다.

   • true이면 3단계로 계속합니다.
   • false이면 상태 변경 요청이 이미 성공했음을 확인할 수 있는 경우가 아니라면 412 (사전 조건 실패)로 응답합니다(13.1.4절 참조).

3. If-None-Match가 있으면 If-None-Match 사전 조건을 평가합니다.

   • true이면 5단계로 계속합니다.
   • GET/HEAD에서 false이면 304 (수정되지 않음)으로 응답합니다.
   • 다른 메서드에서 false이면 412 (사전 조건 실패)로 응답합니다.

4. 메서드가 GET 또는 HEAD이고 If-None-Match가 없으며 If-Modified-Since가 있으면 If-Modified-Since 사전 조건을 평가합니다.

   • true이면 5단계로 계속합니다.
   • false이면 304 (수정되지 않음)으로 응답합니다.

5. 메서드가 GET이고 Range와 If-Range가 모두 있으면 If-Range 사전 조건을 평가합니다.

   • true이고 Range가 선택된 표현에 적용 가능하면 206 (부분 콘텐츠)로 응답합니다.
   • 그렇지 않으면 Range 헤더 필드를 무시하고 200 (OK)로 응답합니다.

6. 그렇지 않으면,

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

추가 조건부 요청 헤더 필드를 정의하는 HTTP 확장은 그러한 필드를 이 문서에 정의된 필드 및 실제로 존재할 수 있는 다른 조건과 관련하여 평가하는 순서를 정의하는 것이 바람직합니다.

범위는 범위 단위와 범위 지정자 집합을 함께 사용하여 표현됩니다. 범위 단위 이름은 자체 지정자에 어떤 종류의 range-spec을 적용할 수 있는지 결정합니다. 따라서 다음 문법은 일반적입니다. 각 범위 단위는 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)

ranges-specifier는 표시된 range-unit에 대해 유효하지 않거나 정의되지 않은 range-spec을 포함하면 유효하지 않습니다.

유효한 ranges-specifier는 표시된 range-unit이 정의하는 바에 따라 충족 가능한 range-spec을 하나 이상 포함하면 충족 가능합니다. 그렇지 않으면 ranges-specifier는 충족 불가능합니다.

"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 값을 선택된 표현의 현재 길이보다 1 작은 값으로 대체합니다).

클라이언트는 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, 또는
• 0이 아닌 suffix-length를 가진 suffix-range.

선택된 표현의 길이가 0인 경우 GET 요청의 range-spec에서 충족 가능한 유일한 형식은 0이 아닌 suffix-length를 가진 suffix-range입니다.

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

100(계속) 상태 코드는 요청의 초기 부분이 수신되었으며 아직 서버에 의해 거부되지 않았음을 나타냅니다. 서버는 요청을 완전히 수신하고 처리한 후 최종 응답을 전송하려 합니다.

요청에 100-continue 기대 사항을 포함하는 Expect 헤더 필드가 있으면 100 응답은 서버가 10.1.1절에 설명된 대로 요청 콘텐츠를 수신하려 함을 나타냅니다. 클라이언트는 요청 전송을 계속하고 100 응답을 버리는 것이 바람직합니다.

요청에 100-continue 기대 사항을 포함하는 Expect 헤더 필드가 없었다면 클라이언트는 이 임시 응답을 단순히 버릴 수 있습니다.

101(프로토콜 전환) 상태 코드는 서버가 이 연결에서 사용 중인 애플리케이션 프로토콜을 변경하려는 클라이언트의 요청을 Upgrade 헤더 필드(7.8절)를 통해 이해하고 준수할 의향이 있음을 나타냅니다. 서버는 이 응답 이후 어떤 프로토콜이 적용될지를 나타내는 Upgrade 헤더 필드를 응답에 MUST 생성해야 합니다.

서버는 그렇게 하는 것이 유리한 경우에만 프로토콜 전환에 동의할 것으로 가정합니다. 예를 들어 더 새로운 HTTP 버전으로 전환하면 이전 버전보다 유리할 수 있고, 이러한 기능을 사용하는 리소스를 제공할 때 실시간 동기식 프로토콜로 전환하는 것이 유리할 수 있습니다.

CONNECT에 대한 응답을 제외하면 메시지 프레이밍이 콘텐츠 길이가 0임을 명시적으로 나타내지 않는 한 200 응답에는 메시지 콘텐츠가 포함될 것으로 예상됩니다. 요청의 어떤 측면이 성공 시 콘텐츠가 없기를 선호함을 나타내면 오리진 서버는 대신 204 (콘텐츠 없음) 응답을 전송하는 것이 바람직합니다. CONNECT의 경우 성공 결과는 200 응답 헤더 섹션 직후 시작되는 터널이므로 콘텐츠가 없습니다.

200 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

GET 또는 HEAD에 대한 200 응답에서 오리진 서버는 선택된 표현에 사용 가능한 모든 검증자 필드(8.8절)를 SHOULD 전송해야 하며, 강한 엔터티 태그와 Last-Modified 날짜를 모두 제공하는 것이 선호됩니다.

상태 변경 메서드에 대한 200 응답에서 응답으로 전송된 모든 검증자 필드(8.8절)는 요청 의미론을 성공적으로 적용한 결과 형성된 새 표현의 현재 검증자를 전달합니다. PUT 메서드(9.3.4절)에는 그러한 검증자 전송을 배제할 수 있는 추가 요구사항이 있음에 유의하십시오.

201(생성됨) 상태 코드는 요청이 충족되었으며 그 결과 하나 이상의 새 리소스가 생성되었음을 나타냅니다. 요청으로 생성된 주 리소스는 응답의 Location 헤더 필드 또는 Location 헤더 필드가 수신되지 않은 경우 대상 URI로 식별됩니다.

201 응답 콘텐츠는 일반적으로 생성된 리소스를 설명하고 해당 리소스로 연결합니다. 응답으로 전송된 모든 검증자 필드(8.8절)는 요청으로 생성된 새 표현의 현재 검증자를 전달합니다. PUT 메서드(9.3.4절)에는 그러한 검증자 전송을 배제할 수 있는 추가 요구사항이 있음에 유의하십시오.

202(수락됨) 상태 코드는 요청이 처리를 위해 수락되었지만 처리가 완료되지 않았음을 나타냅니다. 실제 처리가 이루어질 때 허용되지 않을 수 있으므로 요청이 결국 처리될 수도 있고 그렇지 않을 수도 있습니다. HTTP에는 비동기 작업에서 상태 코드를 다시 전송하는 기능이 없습니다.

202 응답은 의도적으로 확정적이지 않습니다. 그 목적은 사용자 에이전트와 서버 간의 연결을 프로세스가 완료될 때까지 유지할 필요 없이 서버가 다른 프로세스(아마 하루에 한 번만 실행되는 배치 지향 프로세스)에 대한 요청을 수락할 수 있도록 하는 것입니다. 이 응답과 함께 전송되는 표현은 요청의 현재 상태를 설명하고 요청이 언제 충족될지에 대한 추정치를 사용자에게 제공할 수 있는 상태 모니터를 가리키거나 포함하는 것이 바람직합니다.

203(비권위 정보) 상태 코드는 요청이 성공했지만 포함된 콘텐츠가 변환 프록시(7.7절)에 의해 오리진 서버의 200 (OK) 응답 콘텐츠에서 수정되었음을 나타냅니다. 이 상태 코드를 통해 프록시는 변환이 적용되었을 때 수신자에게 알릴 수 있습니다. 이러한 정보가 콘텐츠에 관한 이후 결정에 영향을 줄 수 있기 때문입니다. 예를 들어 콘텐츠에 대한 향후 캐시 검증 요청은 동일한 요청 경로 (동일한 프록시를 통함)에서만 적용될 수 있습니다.

203 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

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

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

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

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

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

204 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

205(콘텐츠 재설정) 상태 코드는 서버가 요청을 충족했으며 사용자 에이전트가 요청을 전송하게 한 "문서 뷰"를 오리진 서버에서 수신한 원래 상태로 재설정하기를 원함을 나타냅니다.

이 응답은 사용자가 데이터 입력을 지원하는 콘텐츠(양식, 메모장, 캔버스 등)를 수신하고, 해당 공간에 데이터를 입력하거나 조작하고, 입력한 데이터를 요청으로 제출한 다음, 사용자가 다른 입력 동작을 쉽게 시작할 수 있도록 다음 입력을 위해 데이터 입력 메커니즘을 재설정하는 일반적인 데이터 입력 사용 사례를 지원하기 위한 것입니다.

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

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

범위 요청(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 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

300(여러 선택지) 상태 코드는 대상 리소스에 각각 더 구체적인 자체 식별자를 가진 둘 이상의 표현이 있으며, 사용자(또는 사용자 에이전트)가 요청을 해당 식별자 중 하나 이상으로 리디렉션하여 선호 표현을 선택할 수 있도록 대안에 관한 정보가 제공되고 있음을 나타냅니다. 즉 서버는 사용자 에이전트가 자신의 요구에 가장 적절한 표현을 선택하기 위해 반응형 협상에 참여하기를 원합니다(12절).

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

HEAD 이외의 요청 메서드에 대해 서버는 사용자가 가장 선호하는 것을 선택할 수 있는 표현 메타데이터와 URI 참조 목록을 포함하는 콘텐츠를 300 응답에 SHOULD 생성해야 합니다. 사용자 에이전트는 제공된 미디어 유형을 이해한다면 해당 목록에서 자동으로 선택할 MAY 수 있습니다. HTTP는 콘텐츠 정의와 독립적으로 유지하려 하므로 자동 선택을 위한 특정 형식은 이 사양에서 정의하지 않습니다. 실제로 표현은 공유 설계나 콘텐츠 협상에 따라 사용자 에이전트가 허용할 수 있다고 판단되는 쉽게 구문 분석 가능한 형식이나 일반적으로 허용되는 하이퍼텍스트 형식으로 제공됩니다.

300 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

301(영구 이동) 상태 코드는 대상 리소스에 새 영구 URI가 할당되었으며 향후 이 리소스에 대한 참조는 포함된 URI 중 하나를 사용하는 것이 바람직함을 나타냅니다. 서버는 링크 편집 기능이 있는 사용자 에이전트가 대상 URI에 대한 참조를 서버가 전송한 새 참조 중 하나로 영구적으로 대체할 수 있음을 제안합니다. 그러나 사용자 에이전트가 실제로 참조를 편집하고 있고(예: 콘텐츠 작성 중), 연결이 보호되며 오리진 서버가 편집 중인 콘텐츠에 대한 신뢰할 수 있는 권한자인 경우가 아니라면 이 제안은 일반적으로 무시됩니다.

서버는 새 영구 URI에 대한 선호 URI 참조를 포함하는 Location 헤더 필드를 응답에 SHOULD 생성해야 합니다. 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 MAY 사용할 수 있습니다. 서버의 응답 콘텐츠에는 일반적으로 새 URI로 연결되는 하이퍼링크가 있는 짧은 하이퍼텍스트 메모가 포함됩니다.

301 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

302(발견됨) 상태 코드는 대상 리소스가 일시적으로 다른 URI에 있음을 나타냅니다. 리디렉션은 때때로 변경될 수 있으므로 클라이언트는 향후 요청에도 대상 URI를 계속 사용하는 것이 바람직합니다.

서버는 다른 URI에 대한 URI 참조를 포함하는 Location 헤더 필드를 응답에 SHOULD 생성해야 합니다. 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 MAY 사용할 수 있습니다. 서버의 응답 콘텐츠에는 일반적으로 다른 URI로 연결되는 하이퍼링크가 있는 짧은 하이퍼텍스트 메모가 포함됩니다.

303(다른 위치 참조) 상태 코드는 서버가 Location 헤더 필드의 URI로 표시되는 다른 리소스로 사용자 에이전트를 리디렉션하고 있으며, 해당 리소스가 원래 요청에 대한 간접 응답을 제공하도록 의도되었음을 나타냅니다. 사용자 에이전트는 해당 URI를 대상으로 검색 요청(HTTP를 사용하는 경우 GET 또는 HEAD 요청)을 수행할 수 있으며, 이 요청도 리디렉션될 수 있고 최종 결과를 원래 요청에 대한 응답으로 제시할 수 있습니다. Location 헤더 필드의 새 URI는 대상 URI와 동등한 것으로 간주되지 않음에 유의하십시오.

이 상태 코드는 모든 HTTP 메서드에 적용할 수 있습니다. 주로 POST 동작의 출력을 다른 리소스로 사용자 에이전트를 리디렉션하는 데 사용하며, 그렇게 하면 POST 응답에 대응하는 정보를 별도로 식별하고 북마크하고 캐시할 수 있는 리소스로 제공할 수 있기 때문입니다.

GET 요청에 대한 303 응답은 오리진 서버가 HTTP를 통해 서버가 전송할 수 있는 대상 리소스의 표현을 가지고 있지 않음을 나타냅니다. 그러나 Location 필드 값은 대상 리소스를 설명하는 리소스를 참조하므로, 그 다른 리소스에 검색 요청을 하면 원래 대상 리소스를 표현한다는 의미 없이 수신자에게 유용한 표현을 얻을 수 있습니다. 무엇을 표현할 수 있는지, 어떤 표현이 적절한지, 무엇이 유용한 설명일 수 있는지는 HTTP의 범위를 벗어남에 유의하십시오.

HEAD 요청에 대한 응답을 제외하면 303 응답의 표현에는 Location 헤더 필드에 제공된 것과 동일한 URI 참조로 연결되는 하이퍼링크가 포함된 짧은 하이퍼텍스트 메모가 있는 것이 바람직합니다.

304(수정되지 않음) 상태 코드는 조건부 GET 또는 HEAD 요청을 수신했고, 조건 평가 결과가 false라는 사실이 아니었다면 200 (OK) 응답이 생성되었을 것임을 나타냅니다. 즉 요청이 조건부가 되도록 만든 클라이언트가 이미 유효한 표현을 가지고 있다고 나타내므로 서버가 대상 리소스의 표현을 전송할 필요가 없습니다. 따라서 서버는 클라이언트가 저장된 표현을 200 (OK) 응답의 콘텐츠인 것처럼 사용하도록 리디렉션합니다.

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

304 응답의 목적은 수신자가 이미 하나 이상의 캐시된 표현을 가지고 있을 때 정보 전송을 최소화하는 것이므로 송신자는 위에 나열된 필드 이외의 표현 메타데이터를 해당 메타데이터가 캐시 갱신을 안내하기 위한 목적이 아니라면 SHOULD NOT 생성해야 합니다(예: 응답에 ETag 필드가 없다면 Last-Modified가 유용할 수 있음).

304 응답을 수신한 캐시에 대한 요구사항은 [CACHING]의 4.3.4절에 정의되어 있습니다. 조건부 요청이 자체 캐시를 가진 사용자 에이전트가 공유 프록시에 조건부 GET을 전송하는 경우처럼 아웃바운드 클라이언트에서 시작되었다면 프록시는 해당 클라이언트에 304 응답을 SHOULD 전달해야 합니다.

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

305(프록시 사용) 상태 코드는 이 사양의 이전 버전에서 정의되었으며 현재는 폐기되었습니다( [RFC7231]의 부록 B).

306 상태 코드는 이 사양의 이전 버전에서 정의되었지만 더 이상 사용되지 않으며 해당 코드는 예약되어 있습니다.

307(임시 리디렉션) 상태 코드는 대상 리소스가 일시적으로 다른 URI에 있으며 사용자 에이전트가 해당 URI로 자동 리디렉션을 수행할 경우 요청 메서드를 MUST NOT 변경해야 함을 나타냅니다. 리디렉션은 시간이 지나면서 변경될 수 있으므로 클라이언트는 향후 요청에 원래 대상 URI를 계속 사용하는 것이 바람직합니다.

서버는 다른 URI에 대한 URI 참조를 포함하는 Location 헤더 필드를 응답에 SHOULD 생성해야 합니다. 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 MAY 사용할 수 있습니다. 서버의 응답 콘텐츠에는 일반적으로 다른 URI로 연결되는 하이퍼링크가 있는 짧은 하이퍼텍스트 메모가 포함됩니다.

308(영구 리디렉션) 상태 코드는 대상 리소스에 새 영구 URI가 할당되었으며 이 리소스에 대한 향후 참조는 포함된 URI 중 하나를 사용하는 것이 바람직함을 나타냅니다. 서버는 링크 편집 기능이 있는 사용자 에이전트가 대상 URI에 대한 참조를 서버가 전송한 새 참조 중 하나로 영구적으로 대체할 수 있음을 제안합니다. 그러나 사용자 에이전트가 실제로 참조를 편집하고 있고(예: 콘텐츠 작성 중), 연결이 보호되며 오리진 서버가 편집 중인 콘텐츠에 대한 신뢰할 수 있는 권한자인 경우가 아니라면 이 제안은 일반적으로 무시됩니다.

서버는 새 영구 URI에 대한 선호 URI 참조를 포함하는 Location 헤더 필드를 응답에 SHOULD 생성해야 합니다. 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 MAY 사용할 수 있습니다. 서버의 응답 콘텐츠에는 일반적으로 새 URI로 연결되는 하이퍼링크가 있는 짧은 하이퍼텍스트 메모가 포함됩니다.

308 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

400(잘못된 요청) 상태 코드는 클라이언트 오류로 인식되는 문제 (예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍 또는 기만적인 요청 라우팅) 때문에 서버가 요청을 처리할 수 없거나 처리하지 않음을 나타냅니다.

401(인증되지 않음) 상태 코드는 대상 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타냅니다. 401 응답을 생성하는 서버는 대상 리소스에 적용 가능한 하나 이상의 챌린지를 포함하는 WWW-Authenticate 헤더 필드 (11.6.1절)를 MUST 전송해야 합니다.

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

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

403(금지됨) 상태 코드는 서버가 요청을 이해했지만 충족하기를 거부함을 나타냅니다. 요청이 금지된 이유를 공개하려는 서버는 응답 콘텐츠(있는 경우)에 그 이유를 설명할 수 있습니다.

요청에 인증 자격 증명이 제공되었다면 서버는 이를 접근 권한을 부여하기에 충분하지 않은 것으로 간주합니다. 클라이언트는 동일한 자격 증명으로 요청을 자동으로 반복하지 않는 것이 SHOULD NOT 요구됩니다. 클라이언트는 새롭거나 다른 자격 증명으로 요청을 MAY 반복할 수 있습니다. 그러나 요청은 자격 증명과 관련 없는 이유로 금지될 수도 있습니다.

금지된 대상 리소스가 현재 존재함을 "숨기려는" 오리진 서버는 대신 404 (찾을 수 없음) 상태 코드로 MAY 응답할 수 있습니다.

404(찾을 수 없음) 상태 코드는 오리진 서버가 대상 리소스의 현재 표현을 찾지 못했거나 그러한 표현이 존재함을 공개할 의향이 없음을 나타냅니다. 404 상태 코드는 이 표현의 부재가 일시적인지 영구적인지를 나타내지 않습니다. 오리진 서버가 구성 가능한 수단 등을 통해 이 상태가 영구적일 가능성이 높음을 알고 있다면 404보다 410 (사라짐) 상태 코드를 사용하는 것이 바람직합니다.

404 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

405(허용되지 않는 메서드) 상태 코드는 요청 라인에서 수신한 메서드를 오리진 서버가 알고 있지만 대상 리소스가 지원하지 않음을 나타냅니다. 오리진 서버는 대상 리소스가 현재 지원하는 메서드 목록을 포함하는 Allow 헤더 필드를 405 응답에 MUST 생성해야 합니다.

405 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

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

서버는 사용 가능한 표현 특성과 대응하는 리소스 식별자의 목록을 포함하는 콘텐츠를 SHOULD 생성하여 사용자 또는 사용자 에이전트가 가장 적절한 것을 선택할 수 있게 해야 합니다. 사용자 에이전트는 해당 목록에서 가장 적절한 선택지를 자동으로 MAY 선택할 수 있습니다. 그러나 15.4.1절에 설명된 대로 이 사양은 그러한 자동 선택을 위한 표준을 정의하지 않습니다.

407(프록시 인증 필요) 상태 코드는 401 (인증되지 않음)과 유사하지만 클라이언트가 이 요청에 프록시를 사용하려면 자신을 인증해야 함을 나타냅니다. 프록시는 이 요청에 대해 해당 프록시에 적용 가능한 챌린지를 포함하는 Proxy-Authenticate 헤더 필드(11.7.1절)를 MUST 전송해야 합니다. 클라이언트는 새로 만들거나 교체한 Proxy-Authorization 헤더 필드(11.7.2절)를 사용하여 요청을 MAY 반복할 수 있습니다.

408(요청 시간 초과) 상태 코드는 서버가 기다릴 준비가 된 시간 안에 완전한 요청 메시지를 수신하지 못했음을 나타냅니다.

클라이언트에 아직 전송 중인 요청이 있다면 해당 요청을 MAY 반복할 수 있습니다. 현재 연결을 사용할 수 없다면(예: HTTP/1.1에서 요청 구분이 손실된 경우처럼) 새 연결을 사용합니다.

409(충돌) 상태 코드는 대상 리소스의 현재 상태와의 충돌 때문에 요청을 완료할 수 없음을 나타냅니다. 이 코드는 사용자가 충돌을 해결하고 요청을 다시 제출할 수 있을 가능성이 있는 상황에 사용됩니다. 서버는 사용자가 충돌 원인을 인식할 수 있을 만큼 충분한 정보를 포함하는 콘텐츠를 SHOULD 생성해야 합니다.

충돌은 PUT 요청에 대한 응답으로 발생할 가능성이 가장 높습니다. 예를 들어 버전 관리가 사용되고 PUT되는 표현이 이전 (제3자) 요청에서 이루어진 변경과 충돌하는 리소스 변경을 포함한다면 오리진 서버는 요청을 완료할 수 없음을 나타내기 위해 409 응답을 사용할 수 있습니다. 이 경우 응답 표현에는 개정 이력을 바탕으로 차이를 병합하는 데 유용한 정보가 포함될 가능성이 높습니다.

410(사라짐) 상태 코드는 오리진 서버에서 대상 리소스에 더 이상 접근할 수 없으며 이 상태가 영구적일 가능성이 높음을 나타냅니다. 오리진 서버가 이 상태가 영구적인지 알지 못하거나 판단할 수단이 없다면 대신 404 (찾을 수 없음) 상태 코드를 사용하는 것이 바람직합니다.

410 응답은 주로 리소스가 의도적으로 사용할 수 없으며 서버 소유자가 해당 리소스에 대한 원격 링크가 제거되기를 원한다는 것을 수신자에게 알려 웹 유지 관리 작업을 돕기 위한 것입니다. 이러한 상황은 기간 한정 프로모션 서비스나 더 이상 오리진 서버 사이트와 관련이 없는 개인의 리소스에서 흔히 발생합니다. 영구적으로 사용할 수 없는 모든 리소스를 "사라짐"으로 표시하거나 그 표시를 일정 기간 유지할 필요는 없습니다. 이는 서버 소유자의 재량에 맡깁니다.

410 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

411(길이 필요) 상태 코드는 서버가 정의된 Content-Length(8.6절) 없이 요청을 수락하기를 거부함을 나타냅니다. 클라이언트는 요청 콘텐츠 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가하면 요청을 MAY 반복할 수 있습니다.

412(사전 조건 실패) 상태 코드는 요청 헤더 필드에 주어진 하나 이상의 조건이 서버에서 검사했을 때 false로 평가되었음을 나타냅니다(13절). 이 응답 상태 코드를 통해 클라이언트는 현재 리소스 상태(현재 표현 및 메타데이터)에 사전 조건을 두어 대상 리소스가 예상하지 못한 상태인 경우 요청 메서드가 적용되지 않도록 할 수 있습니다.

413(콘텐츠가 너무 큼) 상태 코드는 요청 콘텐츠가 서버가 처리할 의향이 있거나 처리할 수 있는 크기보다 크기 때문에 서버가 요청 처리를 거부함을 나타냅니다. 사용 중인 프로토콜 버전이 허용하는 경우 서버는 요청을 MAY 종료할 수 있습니다. 그렇지 않으면 서버는 연결을 MAY 닫을 수 있습니다.

상태가 일시적이라면 서버는 그것이 일시적임과 클라이언트가 언제 다시 시도할 수 있는지를 나타내기 위해 Retry-After 헤더 필드를 SHOULD 생성해야 합니다.

414(URI가 너무 김) 상태 코드는 대상 URI가 서버가 해석할 의향이 있는 길이보다 길기 때문에 서버가 요청 처리를 거부함을 나타냅니다. 이 드문 상태는 클라이언트가 긴 쿼리 정보를 가진 POST 요청을 GET 요청으로 잘못 변환했거나, 클라이언트가 리디렉션의 무한 루프에 빠졌거나(예: 자체 접미사를 가리키는 리디렉션된 URI 접두사), 서버가 잠재적인 보안 허점을 악용하려는 클라이언트의 공격을 받는 경우에만 발생할 가능성이 높습니다.

414 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

415(지원되지 않는 미디어 유형) 상태 코드는 콘텐츠가 대상 리소스의 이 메서드에서 지원하지 않는 형식이기 때문에 오리진 서버가 요청 처리를 거부함을 나타냅니다.

형식 문제는 요청에 표시된 Content-Type 또는 Content-Encoding 때문이거나 데이터를 직접 검사한 결과일 수 있습니다.

지원되지 않는 콘텐츠 코딩 때문에 문제가 발생했다면 요청에서 어떤 콘텐츠 코딩이 허용되었을지(있는 경우) 나타내기 위해 Accept-Encoding 응답 헤더 필드(12.5.3절)를 사용하는 것이 바람직합니다.

반면 지원되지 않는 미디어 유형이 원인이었다면 요청에서 어떤 미디어 유형이 허용되었을지 나타내기 위해 Accept 응답 헤더 필드(12.5.1절)를 사용할 수 있습니다.

416(범위를 충족할 수 없음) 상태 코드는 요청의 Range 헤더 필드(14.2절)에 있는 범위 집합이 요청된 범위 중 어느 것도 충족할 수 없거나 클라이언트가 과도한 수의 작은 범위 또는 중첩 범위를 요청했기 때문에 (잠재적인 서비스 거부 공격) 거부되었음을 나타냅니다.

각 범위 단위는 자체 범위 집합을 충족 가능하게 만드는 데 필요한 조건을 정의합니다. 예를 들어 14.1.2절은 bytes 범위 집합을 충족 가능하게 만드는 조건을 정의합니다.

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

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

417(기대 조건 실패) 상태 코드는 요청의 Expect 헤더 필드(10.1.1절)에 주어진 기대 사항을 하나 이상의 인바운드 서버가 충족할 수 없음을 나타냅니다.

[RFC2324]은 HTTP가 오용되는 다양한 방식을 풍자한 만우절 RFC였습니다. 그러한 오용 중 하나는 애플리케이션별 418 상태 코드의 정의였으며, 농담으로 충분히 많이 배포되어 향후 다른 용도로 사용할 수 없게 되었습니다.

따라서 418 상태 코드는 IANA HTTP 상태 코드 레지스트리에 예약되어 있습니다. 이는 현재 이 상태 코드를 다른 애플리케이션에 할당할 수 없음을 나타냅니다. 향후 상황에서 사용이 필요하다면(예: 4NN 상태 코드가 고갈되는 경우) 다른 용도로 다시 할당할 수 있습니다.

421(잘못 전달된 요청) 상태 코드는 요청이 대상 URI에 대한 권위 있는 응답을 생성할 수 없거나 생성할 의향이 없는 서버로 전달되었음을 나타냅니다. 오리진 서버(또는 오리진 서버를 대신하여 작동하는 게이트웨이)는 서버가 구성된 오리진(4.3.1절)과 일치하지 않거나 요청이 수신된 연결 컨텍스트(7.4절)와 일치하지 않는 대상 URI를 거부하기 위해 421을 전송합니다.

421(잘못 전달된 요청) 응답을 수신한 클라이언트는 요청 메서드가 멱등인지 여부와 관계없이 대상 리소스의 오리진에 특화된 새 연결과 같은 다른 연결이나 대체 서비스 [ALTSVC]를 통해 요청을 MAY 다시 시도할 수 있습니다.

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

422(처리할 수 없는 콘텐츠) 상태 코드는 서버가 요청 콘텐츠의 콘텐츠 유형을 이해하고(415 (지원되지 않는 미디어 유형) 상태 코드는 부적절함), 요청 콘텐츠의 구문도 올바르지만 포함된 명령을 처리할 수 없음을 나타냅니다. 예를 들어 XML 요청 콘텐츠에 올바른 형식(즉, 구문상 올바른)이지만 의미상 잘못된 XML 명령이 포함된 경우 이 상태 코드를 전송할 수 있습니다.

426(업그레이드 필요) 상태 코드는 서버가 현재 프로토콜을 사용하여 요청을 수행하기를 거부하지만 클라이언트가 다른 프로토콜로 업그레이드한 후에는 수행할 의향이 있을 수 있음을 나타냅니다. 서버는 필요한 프로토콜을 나타내기 위해 426 응답에 Upgrade 헤더 필드를 MUST 전송해야 합니다 (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(내부 서버 오류) 상태 코드는 서버가 요청을 충족하지 못하게 하는 예상하지 못한 상황을 만났음을 나타냅니다.

501(구현되지 않음) 상태 코드는 서버가 요청을 충족하는 데 필요한 기능을 지원하지 않음을 나타냅니다. 서버가 요청 메서드를 인식하지 못하고 어떠한 리소스에서도 이를 지원할 수 없는 경우 적절한 응답입니다.

501 응답은 휴리스틱하게 캐시할 수 있습니다. 즉 메서드 정의 또는 명시적인 캐시 제어에서 달리 나타내지 않는 한 그렇습니다( [CACHING]의 4.2.2절 참조).

502(잘못된 게이트웨이) 상태 코드는 게이트웨이 또는 프록시로 작동하는 서버가 요청을 충족하려고 접근한 인바운드 서버에서 유효하지 않은 응답을 수신했음을 나타냅니다.

503(서비스 사용 불가) 상태 코드는 일시적인 과부하나 예정된 유지 관리로 인해 서버가 현재 요청을 처리할 수 없음을 나타내며, 일정 시간이 지나면 해소될 가능성이 높습니다. 서버는 클라이언트가 요청을 다시 시도하기 전에 기다릴 적절한 시간을 제안하기 위해 Retry-After 헤더 필드(10.2.3절)를 MAY 전송할 수 있습니다.

504(게이트웨이 시간 초과) 상태 코드는 게이트웨이 또는 프록시로 작동하는 서버가 요청을 완료하기 위해 접근해야 했던 업스트림 서버로부터 적시에 응답을 받지 못했음을 나타냅니다.

505(지원되지 않는 HTTP 버전) 상태 코드는 서버가 요청 메시지에 사용된 HTTP 주 버전을 지원하지 않거나 지원하기를 거부함을 나타냅니다. 서버는 2.5절에 설명된 대로 이 오류 메시지를 제외하면 클라이언트와 동일한 주 버전을 사용하여 요청을 완료할 수 없거나 완료할 의향이 없음을 나타냅니다. 서버는 해당 버전이 지원되지 않는 이유와 해당 서버가 지원하는 다른 프로토콜을 설명하는 표현을 505 응답에 SHOULD 생성해야 합니다.

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

• 메서드 이름(9절 참조)
• 안전 여부("yes" 또는 "no", 9.2.1절 참조)
• 멱등 여부("yes" 또는 "no", 9.2.2절 참조)
• 사양 텍스트를 가리키는 참조

이 네임스페이스에 추가되는 값은 IETF 검토가 필요합니다([RFC8126], 4.8절 참조).

표준화된 메서드는 일반적입니다. 즉 특정 미디어 유형, 리소스 종류 또는 애플리케이션 하나에만 적용되는 것이 아니라 모든 리소스에 잠재적으로 적용할 수 있습니다. 따라서 새로운 메서드는 단일 애플리케이션이나 데이터 형식에 특화되지 않은 문서에 등록하는 것이 선호됩니다. 독립적인 기술에는 독립적인 사양이 필요하기 때문입니다.

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

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

새 메서드 정의는 안전한지(9.2.1절), 멱등인지(9.2.2절), 캐시 가능한지(9.2.3절), 요청 콘텐츠에 어떤 의미론을 연결할지(있는 경우), 그리고 메서드가 헤더 필드 또는 상태 코드 의미론을 어떻게 세분화하는지를 나타내야 합니다. 새 메서드가 캐시 가능하다면 정의에서 캐시가 응답을 저장하고 이를 후속 요청을 충족하는 데 사용할 수 있는 방법과 조건을 설명하는 것이 바람직합니다. 새 메서드는 조건부로 만들 수 있는지 (13.1절), 가능하다면 조건이 false일 때 서버가 어떻게 응답하는지를 설명하는 것이 바람직합니다. 마찬가지로 새 메서드가 부분 응답 의미론(14.2절)에 사용할 수 있다면 이 역시 문서화하는 것이 바람직합니다.

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

• 상태 코드(3자리)
• 간단한 설명
• 사양 텍스트를 가리키는 참조

HTTP 상태 코드 네임스페이스에 추가되는 값은 IETF 검토가 필요합니다([RFC8126], 4.8절 참조).

현재 상태 코드로 정의되지 않은 응답 의미론을 표현해야 하는 경우 새 상태 코드를 등록할 수 있습니다. 상태 코드는 일반적이며, 특정 미디어 유형, 리소스 종류 또는 HTTP 애플리케이션 하나에만 적용되는 것이 아니라 모든 리소스에 잠재적으로 적용할 수 있습니다. 따라서 새 상태 코드는 단일 애플리케이션에 특화되지 않은 문서에 등록하는 것이 선호됩니다.

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

아직 널리 배포되지 않은 새 상태 코드 제안은 등록될 것이라는 명확한 합의가 있기 전까지 특정 번호를 할당하지 않는 것이 바람직합니다. 대신 초기 초안은 "4NN" 또는 "3N0" .. "3N9" 같은 표기법을 사용하여 번호를 너무 일찍 소비하지 않고 제안된 상태 코드의 클래스를 나타낼 수 있습니다.

새 상태 코드의 정의는 해당 상태 코드를 포함하는 응답을 발생시키는 요청 조건(예: 요청 헤더 필드 및/또는 메서드의 조합)과 응답 헤더 필드에 대한 의존성(예: 어떤 필드가 필수인지, 어떤 필드가 의미론을 수정할 수 있는지, 새 상태 코드와 함께 사용할 때 어떤 필드 의미론이 더 세분화되는지)을 설명하는 것이 바람직합니다.

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

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

마지막으로 새 상태 코드의 정의는 콘텐츠가 식별된 리소스와 암시적으로 관련되어 있는지도 나타내는 것이 바람직합니다(6.4.2절).

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

누구나 HTTP 필드 등록을 요청할 수 있습니다. 새 HTTP 필드를 만들 때 고려해야 할 사항은 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], 4.6절)입니다.

필드 이름:

요청하는 필드 이름입니다. 5.1절에 정의된 field-name 구문을 MUST 준수해야 하며 문자, 숫자 및 하이픈('-') 문자만 사용하고 첫 문자는 문자인 것이 SHOULD 요구됩니다.

상태:

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

사양 문서:

필드를 지정하는 문서에 대한 참조이며, 가능하면 문서 사본을 얻는 데 사용할 수 있는 URI를 포함합니다. provisional 등록에서는 선택 사항이지만 권장됩니다. 관련 절을 나타낼 수도 있지만 필수는 아닙니다.

주석:

예약된 항목에 관한 정보 같은 추가 정보입니다.

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

표준에서 정의된 이름의 상태는 "permanent"입니다. 다른 이름도 전문가가 커뮤니티와 협의하여 실제 사용 중이라고 판단하면 permanent로 등록할 수 있습니다. 그 밖의 이름은 "provisional"로 등록하는 것이 바람직합니다.

provisional 항목은 전문가가 커뮤니티와 협의하여 사용 중이 아니라고 판단하면 제거할 수 있습니다. 전문가는 provisional 항목의 상태를 언제든 permanent로 변경할 수 있습니다.

전문가가 등록되지 않은 이름이 널리 배포되었고 그렇지 않으면 적시에 등록될 가능성이 낮다고 판단한 경우 제3자(전문가 포함)가 이름을 등록할 수 있음에 유의하십시오.

HTTP 헤더 및 트레일러 필드는 프로토콜에서 널리 사용되는 확장 지점입니다. 임시적인 방식으로 사용할 수도 있지만 널리 사용하도록 의도된 필드는 상호운용성을 보장하기 위해 신중하게 문서화해야 합니다.

• 필드를 사용할 수 있는 조건. 예: 응답이나 요청에서만, 모든 메시지에서, 특정 요청 메서드에 대한 응답에서만 등.
• 특정 요청 메서드나 상태 코드와 함께 사용하는 경우처럼 필드 의미론이 컨텍스트에 의해 더 세분화되는지 여부.
• 전달되는 정보의 적용 범위. 기본적으로 필드는 자신이 연결된 메시지에만 적용되지만 일부 응답 필드는 리소스의 모든 표현, 리소스 자체 또는 더 넓은 범위에 적용되도록 설계됩니다. 응답 필드의 범위를 확장하는 사양은 콘텐츠 협상, 적용 기간 및 일부 경우 멀티테넌트 서버 배포 같은 문제를 신중하게 고려해야 합니다.
• 중개자가 필드 값을 삽입, 삭제 또는 수정할 수 있는 조건.
• 필드를 트레일러에서 허용할 수 있는지 여부. 기본적으로는 허용되지 않습니다(6.5.1절 참조).
• 필드 이름을 Connection 헤더 필드에 나열하는 것이 적절하거나 필수인지 여부(즉, 필드가 홉별이어야 하는 경우. 7.6.1절 참조).
• 필드가 개인정보 관련 데이터 공개 같은 추가 보안 고려사항을 도입하는지 여부.

• 필드 이름을 Vary 응답 헤더 필드에 나열하는 것이 적절한지 여부(예: 요청 헤더 필드가 오리진 서버의 콘텐츠 선택 알고리즘에서 사용되는 경우. 12.5.5절 참조).
• PUT 요청에서 수신된 경우 필드를 저장하도록 의도했는지 여부(9.3.4절 참조).
• 보안 문제 때문에 요청을 자동으로 리디렉션할 때 필드를 제거하는 것이 바람직한지 여부(15.4절 참조).

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

• 인증 스킴 이름
• 사양 텍스트를 가리키는 참조
• 참고(선택 사항)

이 네임스페이스에 추가되는 값은 IETF 검토가 필요합니다([RFC8126], 4.8절 참조).

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

• 인증 매개변수 "realm"은 11.5절에 설명된 보호 공간을 정의하기 위해 예약되어 있습니다. 새 스킴은 해당 정의와 호환되지 않는 방식으로 이를 MUST NOT 사용해야 합니다.

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

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

  참고: "realm" 매개변수의 값 구문을 quoted-string으로 제한한 것은 새 매개변수에서 반복해서는 안 되는 잘못된 설계 선택이었습니다.

• 새 스킴의 정의는 알 수 없는 확장 매개변수의 처리 방식을 정의하는 것이 바람직합니다. 일반적으로 "must-understand" 규칙보다 "must-ignore" 규칙이 선호됩니다. 그렇지 않으면 이전 수신자가 있는 상황에서 새 매개변수를 도입하기 어렵기 때문입니다. 또한 새 매개변수를 정의하는 정책 (예: "사양 갱신" 또는 "이 레지스트리 사용")을 설명하는 것이 좋습니다.

• 인증 스킴은 오리진 서버 인증(즉, WWW-Authenticate 사용) 및/또는 프록시 인증(즉, Proxy-Authenticate 사용)에서 사용할 수 있는지 문서화해야 합니다.

• Authorization 헤더 필드에 전달되는 자격 증명은 사용자 에이전트에 특화되어 있으므로 해당 자격 증명이 나타나는 요청 범위에서 HTTP 캐시에 "private" 캐시 응답 지시어( [CACHING]의 5.2.2.7절)와 동일한 영향을 줍니다.

  따라서 자격 증명을 Authorization 헤더 필드에 전달하지 않기로 선택한 새 인증 스킴(예: 새로 정의된 헤더 필드 사용)은 캐시 응답 지시어 (예: "private") 사용을 의무화하여 캐싱을 명시적으로 금지해야 합니다.

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

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

• 이름
• 설명
• 사양 텍스트를 가리키는 참조

이 네임스페이스에 추가되는 값은 IETF 검토가 필요합니다([RFC8126], 4.8절 참조).

페이지, 절, 레코드, 행 또는 시간 같은 형식별 경계 등 다른 범위 단위도 애플리케이션별 목적으로 HTTP에서 사용할 수 있지만 실제로는 일반적으로 사용되지 않습니다. 대체 범위 단위의 구현자는 콘텐츠 코딩 및 범용 중개자와 어떻게 작동할지 고려하는 것이 바람직합니다.

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

• 이름
• 설명
• 사양 텍스트를 가리키는 참조

인코딩 변환이 동일한 경우(8.4.1절에 정의된 압축 코딩처럼)가 아니라면 콘텐츠 코딩의 이름은 전송 코딩의 이름("HTTP Transfer Coding Registry", https://www.iana.org/assignments/http-parameters/에 위치)과 MUST NOT 겹쳐야 합니다.

이 네임스페이스에 추가되는 값은 IETF 검토( [RFC8126]의 4.8절)가 필요하며 8.4.1절에 정의된 콘텐츠 코딩의 목적에 MUST 부합해야 합니다.

새 콘텐츠 코딩은 가능한 경우 자체 기술적이어야 하며, 선택적 매개변수는 전송 중 손실될 수 있는 외부 메타데이터에 의존하기보다 코딩 형식 자체에서 발견할 수 있는 것이 바람직합니다.

HTTP 인증 프레임워크는 자격 증명의 기밀성을 유지하기 위한 단일 메커니즘을 정의하지 않습니다. 대신 각 인증 스킴이 전송 전에 자격 증명을 인코딩하는 방식을 정의합니다. 이는 향후 인증 스킴 개발에 유연성을 제공하지만 자체적으로 기밀성을 제공하지 않거나 재생 공격에 대해 충분히 보호하지 못하는 기존 스킴을 보호하기에는 충분하지 않습니다. 또한 서버가 개별 사용자별 자격 증명을 기대한다면 자격 증명 안의 콘텐츠가 기밀로 유지되더라도 해당 자격 증명의 교환 자체가 사용자를 식별하는 효과를 갖습니다.

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

기존 HTTP 클라이언트와 사용자 에이전트는 일반적으로 인증 정보를 무기한 유지합니다. HTTP는 자격 증명이 사용자 에이전트에 의해 어떻게 얻어지거나 관리되는지 프로토콜이 인식하지 못하므로 오리진 서버가 클라이언트에 캐시된 자격 증명을 버리도록 지시하는 메커니즘을 제공하지 않습니다. 자격 증명을 만료하거나 취소하는 메커니즘은 인증 스킴 정의의 일부로 지정할 수 있습니다.

• 클라이언트가 장시간 유휴 상태였고 이후 서버가 클라이언트가 사용자에게 자격 증명을 다시 요청하도록 하려는 경우.
• 애플리케이션에 세션 종료 표시(예: 페이지의 "logout" 또는 "commit" 버튼)가 포함되어 있고 그 이후 애플리케이션의 서버 측이 클라이언트가 자격 증명을 계속 유지할 이유가 없다고 "알고" 있는 경우.

자격 증명을 캐시하는 사용자 에이전트는 사용자가 제어하여 캐시된 자격 증명을 버릴 수 있는 쉽게 접근 가능한 메커니즘을 제공하는 것이 권장됩니다.

보호 공간을 설정할 때 "realm" 메커니즘에만 의존하는 인증 스킴은 오리진 서버의 모든 리소스에 자격 증명을 노출합니다. 어떤 리소스에 인증된 요청을 성공적으로 수행한 클라이언트는 동일한 오리진 서버의 다른 리소스에 같은 인증 자격 증명을 사용할 수 있습니다. 이로 인해 다른 리소스가 다른 리소스의 인증 자격 증명을 수집할 수 있습니다.

이는 오리진 서버가 동일한 오리진 아래에서 여러 당사자의 리소스를 호스팅할 때 특히 문제가 됩니다(11.5절). 가능한 완화 전략으로는 인증 자격 증명에 대한 직접 접근을 제한하는 것 (즉, Authorization 요청 헤더 필드의 콘텐츠를 제공하지 않음)과 각 당사자에 서로 다른 host 이름(또는 port 번호)을 사용하여 보호 공간을 분리하는 것이 있습니다.

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