HTTP 헤더 필드 정의

이 섹션은 HTTP/1.1의 모든 표준 헤더 필드에 형식과 의미를 정의한다. Entity-Header 필드에서 발송자와 수신측은 누가 엔터티를 발송하고 누가 엔터티를 수신하는가에 따라 클라이언트 또는 서버 모두를 지칭할 수 있다. 

14.1.  ACCEPT
Accept request-header 필드는 응답에 사용할 수 있는 특정 media type을 명시하는 데 사용할 수 있다. Accept 헤더는 라인에 포함된 이미지(in-line image)에 대한 요구처럼 요구가 상세하게 원하는 유형의 작은 세트에 한정되어 있음을 표시하는 데 사용한다. 

Accept           =       "Accept" ":"                                  #( media-range [ accept-params ] )    media-range   =       ( "*/*"                                  | ( type "/" "*" )                                  | ( type "/" subtype )                                  ) *( ";" parameter )   accept-params         =       ";" "q" "=" qvalue *( accept-extension )   accept-extension      =       ";" token [ "=" ( token | quoted-string ) ]

별표("*") 문자는 media type을 영역으로 그룹핑하는 데 사용한다. "*/*"는 모든 media type을, "type/*은 해당 type의 모든 subtype을 표시한다. Media-range는 해당 영역에 적용할 수 있는 media type 파라미터를 포함할 수 있다. 

모든 media-range에는 하나 또는 그 이상의 상대적 품질 요소를 표시하는 "q" 파라미터로 시작하는 accept-params가 뒤따른다. 처음의 "q" 파라미터(있다면)는 media-range 파라미터를 accept-params로부터 분리시킨다. 품질 요소(quality factor)는 사용자 또는 사용자 에이전트가 qvalue(섹션 3.9) 척도를 0부터 1까지 사용하여 해당 media-range에 대한 상대적 선호도를 표시할 수 있도록 한다. 기본값은 q=1이다. 

주의 : "q" 파라미터 이름을 media type 파라미터를 Accept 확장 파라미터로부터 분리하는 데 사용하는 것은 계속적인 관행 때문이다. 이 관행이 어떠한 media type 파라미터에도 "q"라는 이름을 media range에 사용할 수 없게 하지만 IATA media type 등록표에서 "q" 파라미터가 많이 사용되지 않고 있고 Accept에서 media type 파라미터를 잘 사용하지 않는다는 점을 감안할 때 이러한 경우는 발생하기 어렵다. 향후 media type은 "q"라는 이름의 파라미터를 등록하지 말아야 한다. 

예: 

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

위의 문장은 "나는 audio/basic을 선호하지만 80% 이하로 질이 떨어지면 사용할 수 있는 가장 좋은 다른 audio type을 발송해 주시오."로 해석해야 한다. 

Accept 헤더 필드가 없다면 클라이언트가 모든 media type을 수용한다고 가정한다. Accept 헤더 필드가 있고 서버가 결합된 Accpet 필드 값에 적합한 응답을 발송할 수 없을 때 서버는 406 (not acceptable) 응답을 발송해야 한다. 

좀더 자세한 예는 

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

말로 표현한다면 이것을 "text/html 및 text/x-c가 선호하는 media type이지만 이것이 존재하지 않으면 text/x-dvi 엔터티를 발송하고 존재하면 text/plain 엔터티를 발송하시오."라고 해석할 수 있다. 

Media ranges는 좀더 상세한 media range 및 media type에 의하여 무시될 수 있다. 특정 type에 하나 이상의 media range를 적용했을 때 가장 상세한 것이 우선권을 갖는다. 예를 들면, 

Accept: text/*, text/html, text/html;level=1, */*

은 다음의 우선순위를 가진다. 

1) text/html;level=1 
2) text/html 
3) text/* 
4) */*

특정 type과 관련된 media type 품질 요소는 해당 type에 일치하는 media range 중 최고의 우선권을 갖는 것을 발견하여 결정한다. 예를 들어, 

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,               text/html;level=2;q=0.4, */*;q=0.5

는 아래와 같은 값이 연관되도록 한다.

 text/html;level=1          =       1 

 text/html                     =       0.7 
 text/plain                    =       0.3 
 image/jpeg                 =       0.5 
 text/html;level=2          =       0.4 
 text/html;level=3          =       0.7

주의: 사용자 에이전트는 특정 media range에 대한 품질의 기본 값 세트를 가지고 있을 수 있다. 

그러나 사용자 에이전트가 다른 표시 에이전트와 상호 작용할 수 없는 폐쇄된 시스템이 아니라면 기본 값 세트는 사용자가 설정할 수 있어야 한다. 


14.2. ACCEPT-CHARSET 
Accept-Charset request-header 필드는 응답에 사용할 수 있는 문자 조합을 표시하는 데 사용한다. 이 필드는 광범위하고 전문적인 목적의 문자 조합을 이해할 수 있는 클라이언트가 이러한 문자 조합으로 문서를 표시할 수 있는 서버에게 자신의 능력을 알려 줄 수 있도록 한다. 모든 클라이언트는 ISO-8859-1문자 조합을 사용할 수 있는 것으로 가정한다. 

Accept-Charset = "Accept-Charset" ":"                             1#( charset [ ";" "q" "=" qvalue ] )

          
문자 조합 값은 3.4 절에 설명되어 있다. 각각의 charset는 해당 charset에 대한 사용자의 선호 사항을 표시하는 관련된 품질 값을 가질 수 있다. 기본값은 q=1이며 예는 다음과 같다. 

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

          
Accept-Charset 헤더가 있으면 기본값은 모든 문자 조합을 사용할 수 있다. Accept-Charset 헤더가 있고 서버가 Accept-Charset 헤더를 사용할 수 있는 응답을 발송할 수 없을 때 비록 응답을 발송할 수는 있지만 서버는 406 (not acceptable) 상태 코드의 에러 메시지를 발송해야 한다. 



14.3. ACCEPT-ENCODING 
Accept-Encoding request-header 필드는 Accept와 유사하지만 응답에서 사용할 수 있는 content-coding 값(섹션 14.12)에 제한이 있다. 

Accept-Encoding  = "Accept-Encoding" ":"                                #( content-coding )

       
이의 사용 예는, 

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

요청에 Accept-Encoding 헤더가 없으면 서버는 클라이언트가 어떠한 content coding도 접수할 수 있다고 가정할 수 있다. Accept-Encoding 헤더가 있고 서버가 Accept- Encoding 헤더를 사용할 수 있는 응답을 발송할 수 없을 때 비록 응답을 발송할 수는 있지만 서버는 406 (not acceptable) 상태 코드의 에러 메시지를 발송해야 한다. 

값이 비어 있으면 아무 것도 접수할 수 없음을 표시한다. 


14.4. ACCEPT-LANGUAGE 
Accept-Language request-header 필드는 Accept와 유사하지만 요구에 대한 응답으로 사용할 수 있는 자연스러운 언어(natural languages) 세트에 제한이 있다. 

Accept-Language       =       "Accept-Language" ":"                                             1#( language-range [ ";" "q" "=" qvalue ] )   language-range          =       ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

         
각각의 language-range는 해당 range가 명시하는 언어에 대한 사용자의 예상 선호 상태를 표시하는 관련 품질 값을 가지고 있다. 품질 기본 값은 "q=1" 이며 예는 다음과 같다. 

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

이것은 "나는 덴마크어를 선호하지만 영국 영어 및 다른 유형의 영어도 접수할 것이다."를 의미한다. 태그가 완전히 동일하거나 접두사 뒤의 첫 태그 문자가 "-" 이면 language-range 는language-tag 와 일치한다. 특수 영역(special range) "*"가 Accept-Language 필드에 있으면 Accept-Language 필드에 있는 다른 range에 일치하지 않는 모든 태그를 일치시켜 준다.
 

주의: 접두사 일치 원칙의 사용은 언어 태그가 사용자가 특정 태그의 언어를 이해한다면 이 사용자는 이 태그가 접두사로 쓰인 모든 언어 태그를 이해할 것이다.라는 것이 항상 사실이라는 방식으로 부여 되었다는 것을 의미하지는 않는다. 접두사 원칙은 단순히 이것이 사실일 경우에만 접두사 사용을 허락하는 것이다. 

Accept-Language 필드의 language-tag가 부여한 언어 품질 요소는 language-tag와 일치하는 필드의 가장 긴 language-range 품질 값이다. 필드의 language-range와 일치하는 태그가 없으면 언어 품질 요소는 0으로 부여된다. 요구에 Accept-Language 헤더가 없으면 서버는 모든 언어를 동등하게 수용할 수 있다고 가정해야 한다. Accept-Language 헤더가 있으면 0 이상의 품질 요소를 부여 받은 모든 언어를 수용할 수 있다. 

모든 요구에 사용자의 전체적인 언어 선호 상태를 포함한 Accept-Language 헤더를 발송하는 것이 사용자의 사생활 보호에 대한 기대에 역행할 수도 있다. 이 문제에 관한 토의는 15.7 절을 참조한다. 

주의: 이해정도(intelligibility)는 개별적인 사용자에 따라 다르므로 클라이언트 애플리케이션은 사용자가 원하는 언어를 선택할 수 있도록 할 것을 추천한다. 선택을 할 수 없으면 요구에 Accept-Language 헤더 필드를 제공해서는 안 된다. 

14.5. ACCEPT-RANGES 
Accept-Ranges response-header 필드는 서버가 자원에 대한 영역 요구(range requests)를 접수하였다는 것을 표시한다. 

Accept-Ranges         =       "Accept-Ranges" ":" acceptable-ranges    acceptable-ranges             =       1#range-unit | "none"

Byte-range 요구를 접수한 원서버는 다음과 같이 발송할 수 있다. 

Accept-Ranges: bytes

       
그러나 반드시 이렇게 해야 하는 것은 아니다. 클라이언트는 관련된 자원에 대해 이 헤더를 수신하지 않고도 byte-range 요구를 생산할 수 있다. 
어떠한 형태의 byte-range 요구도 접수하지 않는 원서버는 다음을 발송하여 클라이언트가 영역 요구를 시도하지 말도록 충고할 수 있다. 

Accept-Ranges: none

         

14.6. AGE 
Age response-header 필드는 원서버가 응답(또는 이의 검증)을 생성한 이후 시간에 대한 발송자의 예상 값을 전달한다. 캐시된 응답은 경과 시간이 신선한 시간(freshness lifetime)을 초과하지 않았으면 "신선하다." 경과 시간 값은 13.2.3절에 기술한 바와 같이 산출한다.

Age = "Age" ":" age-value    age-value = delta-seconds

          
경과 시간 값은 음수가 아닌 십진수 정수이며 시간을 초로 표시한다. 

캐시가 가장 크게 표시할 수 있는 정수 값보다 큰 값을 수신하거나 경과 시간 계산이 오버플로우(overflow)되면 Age 헤더의 값을 반드시 2147483648 (2^31)로 전송해야 한다. HTTP/1.1 캐시는 모든 응답에 반드시 Age 헤더를 발송해야 한다. 캐시는 최소 31 비트 범위의 사칙연산 유형 값을 사용해야 한다. 


14.7. ALLOW 
Allow entity-header 필드는 Request-URI 가 식별한 자원이 지원하는 method 세트 목록을 표시한다. 이 필드의 용도는 엄격하게 자원과 관련된 유효한 method의 수신을 알리기 위함이다. Allow 헤더 필드는 반드시 405 (Method Not Allowed) 응답 내에 표시되어야 한다. 

Allow          = "Allow" ":" 1#method

          
이의 사용 예는, 

Allow: GET, HEAD, PUT

         
이 필드는 클라이언트가 다른 methods를 사용하고자 시도하는 것을 방지할 수는 없다. 그러나 Allow 헤더 필드가 표시하는 내용은 준수해야만 한다. 사용할 수 있는 실제 세트는 각 요구가 발송되는 시점에서 원서버가 결정한다. 

Allow 헤더 필드에 PUT 요청을 새롭거나 변경된 자원이 지원하는 method를 추천하기 위해 포함할 수 있다. 서버가 반드시 이러한 method를 지원할 필요는 없으나 실제적으로 사용할 수 있는 method를 제공하는 Allow 헤더 필드를 응답에 포함해야만 한다. 

프락시는 명시된 모든 method를 이해하지 못하더라도 사용자 에이전트가 다른 수단을 통하여 원서버와 통신할 수도 있기 때문에 Allow 
헤더 필드를 변경해서는 절대로 안 된다. 

Allow 헤더 필드는 서버 수준에서 어떠한 method가 구현되었는가 표시하지 않는다. 서버는 전체적으로 서버 상에서 어떠한 method가 구현되었는가 표시하기 위해 Public response-header 필드(섹션 14.35)를 사용할 수 있다. 


14.8. AUTHORIZATION 
서버에서 자신을 인증하고자 하는 사용자 에이전트는(꼭 그런 것은 아니지만 대개의 경우 401 응답을 수신한 후) 요구에 Authorization request-header 필드를 포함하여 자신의 인증 획득을 시도할 수 있다. Authorization 필드 값은 요구하고 있는 자원의 영역에 대한 사용자 에이전트의 인증 획득 정보를 포함하고 있는 보증서(credentials)로 구성되어 있다. 

Authorization  = "Authorization" ":" credentials

         
HTTP 접속 인증 획득은 11장에 기술되어 있다. 요구에 대한 인증을 획득하고 영역이 명시되면 동일한 보증서는 해당 영역 내의 다른 요구에 대해서도 유효해야 한다. 

공유된 캐시(13.절 참조)가 필드가 포함된 요구를 수신하면 캐시는 다음에 명시된 예외 사항 이외에는 다른 요구에 대한 대답으로서 해당 응답을 리턴해서는 절대 안 된다. 

1. 응답이  "proxy-revalidate" Cache-Control 지시자를 포함하고 있지 않으면 캐시는 해당 응답을 계속되는 요구에 대한 대답으로 사용할 수 있다. 그러나 프락시 캐시는 원서버가 새로운 요구를 인증할 수 있도록 새로운 요구의 request-header를 이용하여 반드시 먼저 새로운 요구를 재검증해야 한다.
2. 응답이  "proxy-revalidate" Cache-Control 지시자를 포함하고 있으면 캐시는 해당 응답을 계속되는 요구에 대한 대답으로 사용할 수 있다. 그러나 모든 캐시는 원서버가 모든 요구를 인증할 수 있도록 새로운 요구의 request-header를 이용하여 반드시 먼저 새로운 요구를 재검증해야 한다.
3. 응답이 " public" Cache-Control 지시자를 포함하고 있으면 이를 계속되는 요구에 대한 대답으로 리턴할 수 있다. 
   

14.9. CACHE-CONTROL 
Cache-Control general-header 필드는 Request/Response chain에 따라 모든 캐시 메커니즘이 반드시 따라야 하는 지시자를 표시하는 데 사용한다. 지시자는 캐시가 요구나 응답을 바람직하지 못하게 방해하지 못하도록 하는 행태(behavior)를 명시한다. 이러한 지시자들은 대개 기본적인 캐시 알고리즘을 무시한다. 캐시 지시자 요구에 지시자가 존재한다는 것이 응답에도 동일한 지시자를 부여해야 한다는 것의 의미하지 않다는 의미에서 단 방향(unidirectional)이다. 

주의 : HTTP/1.0 캐시는 Cache-Control을 구현하고 있지 않으면 Pragma: no-cache (14.32절 참조)만을 구현하고 있다는 것에 주의한다. 

캐시 지시자는 Request/Response chain를 따라서 모든 수신측에게 적용할 수 있기 때문에 해당 애플리케이션에서 차지하는 중요도에 관계 없이 프락시나 게이트웨이 애플리케이션은 이 지시자를 반드시 통과시켜야 한다. 특정한 캐시를 위한 cache-directive를 명시하는 것이 불가능하지는 않다. 

Cache-Control         =       "Cache-Control" ":" 1#cache-directive   cache-directive        =       cache-request-directive                            |     cache-response-directive   cache-request-directive =                             "no-cache" [ "=" <"> 1#field-name <"> ]                            | "no-store"                            | "max-age" "=" delta-seconds                            | "max-stale" [ "=" delta-seconds ]                            | "min-fresh" "=" delta-seconds                            | "only-if-cached"                            | cache-extension   cache-response-directive =                              "public"                            | "private" [ "=" <"> 1#field-name <"> ]                            | "no-cache" [ "=" <"> 1#field-name <"> ]                            | "no-store"                            | "no-transform"                            | "must-revalidate"                            | "proxy-revalidate"                            | "max-age" "=" delta-seconds                            | cache-extension   cache-extension = token [ "=" ( token | quoted-string ) ]

        
지시자에 어떠한 1#field-name 파라미터도 없으면 그 지시자는 전체 요구 또는 응답에 적용된다. 지시자에 1#field-name 파라미터가 있으면 그 지시자는 해당 필드 또는 필드들에게만 적용되고 나머지 요구나 응답에는 적용되지 않는다. 이 메커니즘이 확장성을 지원한다. 향후 HTTP 규약의 구현은 HTTP/1.1에 정의되지 않은 헤더 필드에 이 지시자를 적용할 수도 있다. 

Cache-control 지시자는 다음과 같은 일반적인 범주로 분류할 수 있다. 

• 캐시할 수 있는 것에 대한 제한: 오직 원서버만이 제한을 둘 수 있다.
• 기본적인 유효일 메커니즘의 변경: 원서버 및 사용자 에이전트 모두가 부과할 수 있다.
• 캐시 검증이나 갱신에 대한 통제: 오직 원서버만이 통제할 수 있다.
• 엔터티의 변형에 대한 통제.
• 캐시 시스템에 대한 확장(extensions)

14.9.1 무엇을 캐시할 수 있는가 
기본적으로 요구 method의 요구사항, 요구 헤더 필드, 응답 상태가 캐시할 수 있다고 표시하는 응답은 캐시할 수 있다. 13.4절은 캐시할 수 있는 기본값들에 대하여 요약해 놓았다. 다음의 Cache-Control 응답 지시자는 원서버가 응답의 캐시 가능성을 무시할 수 있도록 한다.

• public
  보통 비 공유 캐시 내에서만 캐시할 수 있거나 캐시할 수 없지만 어떤 캐시이든 응답을 캐시할 수 있음(cachable)을 표시한다.(추가적인 정보는 14.8절의 Authorization 참조) 
• private
  응답 메시지의 전체 혹은 일부분을 단일 사용자만이 사용하며 절대 공유 캐시(shared cache)에 의해 캐시해서는 안됨을 표시한다. 원서버가 응답의 특정 부분이 단일 사용자만을 위한 것이며 다른 사용자의 요구에 대한 유효한 응답은 아니라는 것을 명시할 수 있도록 한다. 사적인(비 공유) 캐시는 응답을 캐시할 수도 있다.
  주의: 사적이라는 단어 사용의 의미는 응답을 캐시할 수 있는 부분만을 통제하는 것이며 메시지 내용에 대한 보호를 확보할 수는 없다.
• no-cache
  응답의 전체 혹은 부분을 반드시 캐시해야 함을 표시해야 한다. 원서버가 클라이언트 요구에 낡은 응답(stale response)을 리턴하도록 설정된 캐시에 의해서도 캐시를 하지 못하도록 한다.
  주의: 대부분의 HTTP/1.0 캐시는 이 지침을 인지하지 못하거나 따르지 않을 것이다. 
  

14.9.2. 캐시에 의해 무엇을 저장할 수 있는가 
저장 금지(no-store) 지시자의 목적은 부주의하게 민감한 정보를 보유(예를 들어 백업 테이프 위에)하거나 배포하는 것을 방지하는 것이다. No-store 지시자는 전체 메시지에 적용되면 응답 및 요구 모두에 발송할 수 있다. 요구 내에 포함하여 발송했으면 캐시는 요구의 어떤 부분 또는 이 요구에 대한 어떠한 응답도 캐시해서는 안 된다. 응답에 발송했으면 캐시는 이 응답의 어떤 부분 또는 응답을 이끌어 낸 요구를 저장해서는 안 된다. 이 지시자는 비 공유 및 공유 캐시에 모두 적용된다. 이 문장의 저장해서는 안 된다의 의미는 캐시가 의도적으로 고정 저장 매체(non-volatile storage)에 정보를 저장해서는 안 되며 비 고정 저장 매체에서는 정보를 전송한 후 최대한 빨리 정보를 삭제하도록 최선의 노력을 다해야 한다는 것이다. 

이 지시자가 응답과 관련 되었을 때도 사용자는 명백하게 이 응답을 캐시 시스템 외부에 저장할 수 있다.(예를 들어 "Save As" 대화상자) 기록 버퍼는 이러한 응답을 일반적 작업의 일 부분으로 저장할 수도 있다. 

이 지시자의 목적은 특정 사용자의 명시된 필요 조건 및 캐시 데이터 구조체에 예상하지 못한 접속을 통한 우발적인 정보의 유출을 걱정하는 서비스 저작자의 필요 조건을 충족시키는 것이다. 어떤 의미에서 이 지시자의 사용이 사생활 보호를 향상 시켜 줄 수 있지만 이것이 사생활을 보호하는 신뢰하거나 충분한 메커니즘은 아니라는 점에 유의해야 한다. 특히 나쁜 의도를 가지거나 타협적인 캐시는 이 지시자를 인지하지 못하거나 복종하지 않을 수 있다. 또한 통신 네트워크는 정보 유출에 취약한 편이다. 

14.9.3.기본적인 만기일 메커니즘의 변경 
원서버는 Expires 헤더(14.21절 참조)를 이용하여 엔터티의 유효 시간을 명시한다.  대안으로 응답에 max-age 지시자를 사용하여 표시할 수도 있다. 

응답에 Expires 및 max-age 지시자가 모두 포함되어 있으면 max-age 지시자가 Expires 헤더가 더 제한적이라 할지라도 이를 무시한다. 이 원칙은 원서버가 HTTP/1.0 캐시에 HTTP/1.1 캐시(또는 이후 버전)보다 긴 유효시간을 응답에 부여할 수 있도록 한다. 어떠한 HTTP/1.0 캐시가 동시화되지 않은(desynchronized) 시계 때문에 부적절하게 경과 시간이나 유효 시간을 계산했을 때 유용하다. 

주의: 이 규격을 따르지 않는 대부분의 이전 캐시는 Cache-Control 지시자를 구현하지 않는다. Cache-Control 지시자를 사용하기 원하지만 HTTP/1.1을 따른 캐시를 금지하는 않지만 제한하는 원서버는 max-age 지시자가 Expires 헤더를 무시하며 HTTP/1.1을 따르지 않는 캐시는 max-age 지시자를 준수하지 않는다는 사실을 이용할 수 있다. 

다른 지시자는 사용자 에이전트가 기본적인 유효일 메커니즘을 변경할 수 있도록 한다. 이러한 지시자는 요구에 명시할 수 있다. 

• max-age
  클라이언트가 초로 표시된 시간보다 크지 않은 경과 시간을 가진 응답을 기꺼이 접수한다는 것을 표시한다. Max-stale 지시자도 포함되어 있지 않으면 클라이언트는 낡은 응답을 접수할 의사가 없는 것이다.
• min-fresh
  클라이언트가 신선한 기간이 초로 표시된 현재 의 경과 시간보다 크지 않은 응답을 기꺼이 접수한다는 것을 표시한다. 이는 클라이언트가 최소한 초로 표시된 기간 동안만은 신선한 응답을 원하는 것이다.
• max-stale
  클라이언트가 유효시간을 초과한 응답을 기꺼이 접수한다는 것을 표시한다. Max-stale에 값이 부여되었으면 클라이언트는 명시된 초를 초과하지 않는 응답을 기꺼이 접수한다. Max-stale에 값이 부여되지 않았으면 클라이언트는 모든 응답을 기꺼이 접수한다.
  캐시가 요구의 max-stale지시자 응답의 유효 시간을 무시하도록 설정되어 낡은 응답을 리턴하면 캐시는 반드시 Warning 10 (Response is stale)을 이용하여 Warning 헤더를 낡은 응답에 부착하여야 한다. 
  

14.9.4. 캐시의 재검증 및 RELOAD 제어 
때때로 사용자 에이전트는 캐시가 원서버에서 캐시를 재검증하거나 원서버에서 캐시 엔트리를 갱신할 것을(원서버로 향한 경로의 다음 캐시만이 아닌) 원하거나 고집할 수 있다. End-to-end 재검증은 캐시나 원서버가 캐시된 응답의 유효 시간을 과대 평가했을 때 필요할 수 있다. End-to-end 갱신은 어떠한 이유 때문에 캐시 엔트리가 오염되었을 때 필요하다. 

클라이언트가 자신의 지역 캐시 사본을 가지고 있지 않거나("명시되지 않은 end-to-end 재검증"이라 부른다), 가지고 있을 때("명시된 end-to-end 재검증이라 부른다.)End-to-end 재검증을 요구할 수 있다. 

클라이언트는 Cache-Control 지시자를 사용하여 다음의 세 가지 처리를 명시할 수 있다. 

• End-to-end reload
  요구에 "no-cache" Cache-Control 지시자가 포함되어 있거나 HTTP/1.0클라이언트와의 호환성 유지를 위해 "Pragma: no-cache"를 포함하고 있다. 요청의 no-cache 지시자에는 아무런 필드 이름도 포함되지 않는다. 서버는 이러한 요구에 응답할 때 캐시된 사본을 사용해서는 안 된다.
• Specific end-to-end revalidation
  요구가 원서버로 향한 경로를 따라 각각의 캐시가 자신의 엔트리를 다음 캐시나 원 서버와 재검증하도록 강요하는 "max-age=0" Cache-Control 지시자를 포함하고 있다. 첫 요구는 클라이언트의 현재 검증자와 더불어 캐시-검증 조건을 포함하고 있다.
• Unspecified end-to-end revalidation
  요구가 원서버로 향한 경로를 따라 각각의 캐시가 자신의 엔트리를 다음 캐시나 원 서버와 재검증하도록 강요하는 "max-age=0" Cache-Control 지시자를 포함하고 있다. 첫 요구는 클라이언트의 현재 검증자와 더불어 캐시-검증 조건을 포함하고 있지 않다. 해당 자원의 캐시 엔트리를 가지고 있는 경로의 첫 캐시가 현재 검증자와 더불어 캐시-검증 조건을 포함하고 있다
• max-age
  Max-age=0 지시자 때문에 가장 가까운 캐시가 자신의 캐시 엔트리를 재검증하도록 강요 받았을 때 클라이언트는 요구에 자신의 검증자를 제공하며 제공된 검증자는 캐시 엔트리에 현재 저장된 검증자와 상이할 수 있다. 이 경우 캐시는 의미 투명성에 영향을 미치지 않고 자신의 요구를 만드는 데 두 검증자 모두를 사용할 수 있다. 그러나 검증자의 선택이 성능에 영향을 미칠 수 있다. 최상의 접근법은 가장 가까운 캐시가 요구를 만들 때 자기 자신의 검증자를 사용하는 것이다. 서버는 304 (Not Modified)로 응답하고 캐시는 새롭게 검증된 사본을 클라이언트에게 200 (OK) 응답과 함께 되돌려 주어야 한다. 서버가 새로운 엔터티나 캐시 검증자로 응답해도 가장 가까운 캐시는 강한 비교 기능(strong comparison function)을 이용하여 클라이언트의 요구가 제공하는 검증자와 리턴 된 검증자를 비교해야 한다. 클라이언트 검증자가 원서버의 검증자와 동등할 때는 가장 가까운 캐시는 304 (Not Modified)를 리턴한다. 그렇지 않으면 200 (OK) 응답으로 새로운 엔터티를 리턴한다. 요구에 no-cache 지시자가 포함되어 있으면 요구는 min-fresh, max-stale, 또는 max-age를 포함해서는 안 된다.
• only-if-cached
  네트워크 연결이 극도로 약할 때와 같은 경우에 클라이언트는 원서버와 갱신하거나 재검증하는 것이 아닌 현재 저장하고 있는 응답만을 리턴하기 위해 캐시를 원할 수 있다. 이를 위해서 클라이언트는 요구에 only-if-cached 지시자를 포함할 수 있다. 클라이언트가 이 지시자를 수신하면 캐시는 다른 응답의 제한 사항과 일치하는 캐시 엔트리를 사용하여 응답하던지 504 (Gateway Timeout) 상태로 응답할 수 있다. 그러나 캐시의 그룹을 안정된 내부 연결로 통합된 시스템에 사용할 때 이러한 요구는 해당 캐시 그룹 내에서 전달될 수 있다. 
  
• Must-revalidate 
  캐시가 서버에서 명시된 유효 시간을 무시하도록 설정될 수 있기 때문에 또한 클라이언트 요구가 max-stale 지시자를 포함할 수 있기 때문에(유사한 영향을 미친다) 규약은 원서버가 계속되는 캐시 사용에 대한 캐시 엔트리 검증을 요구할 수 있는 메커니즘을 포함하고 있다. Must-revalidate 지시자가 캐시가 수신한 응답에 포함되어 있고 캐시가 계속되는 요구에 응답하기는 낡아진 이후에 캐시는 먼저 원서버에 이를 재검증하기 전에는 엔트리를 사용해서는 안 된다. (예를 들어 캐시는 전적으로 원서버의 Expires 또는 max-age 값에 기초하여 캐시된 응답이 낡았으면 매번 end-to-end 검증을 실행해야 한다.) Must-revalidate 지시자는 특정 규약 기능의 안정된 운영을 위해서 필요하다. 어떠한 경우이든 HTTP/1.1 캐시는 must-revalidate 지시자를 반드시 따라야 한다. 특히 캐시가 어떠한 이유이든 원서버에 도달할 수 없을 때는 반드시  504 (Gateway Timeout) 응답을 생성해야 한다. 서버는 아무런 표시 없이 실행되지 않은 재무 트랜잭션의 경우처럼 엔터티에 대한 재검증이 실패하여 부정확한 운영을 초래할 경우 반드시 must-revalidate 지시자를 발송해야 한다. 수신측은 결코 이 지시자를 위반하는 어떠한 자동화된 처리 방식을 갖고 있어서는 안 되며 재검증이 실패할 경우 자동적으로 검증되지 않은 엔터티 사본을 제공해서는 안 된다. 권하지는 않지만 극도로 악화된 연결 상태를 이용하는 사용자 에이전트는 이 지시자를 위반할 수는 있으나 사용자에게 반드시 검증되지 않은 응답을 제공했음을 명백하게 경고해야 한다. 경고는 검증되지 않는 접속 각각에 제공해야 하며 명백한 사용자 정보를 제공해야 한다.
• Proxy-revalidate 
  Proxy-revalidate 지시자는 비 공유 사용자 에이전트 캐시에는 적용되지 않는다는 점을 제외하고는 must-validate 지시자와 동일한 의미를 갖고 있다. 사용자의 캐시가 응답을 저장하고 나중에 그것을 검증할 필요 없이 리턴할 수 있도록(그 사용자가 먼저 인증을 받았기 때문에) 하면서도 프락시에게 많은 사용자가 재검증하도록 요구하여(각 사용자가 인증되었음을 확실하게 하기 위해) 인증되지 않은 요구에 대한 응답으로 사용할 수 있다. 
  

14.9.5. 비 변경 지시어(NO-TRANSFORM DIRECTIVE) 

• no-transform
  가장 가까운 캐시의 구현자(프락시)는 특정 엔터티 본문의 media type을 변환하는 것이 유용함을 발견할 수 있다. 예를 들어 프락시는 캐시 공간을 절약하거나 느린 링크 상의 트래픽 양을 줄이기 위해 이미지의 포맷을 변환할 수 있다. HTTP는 오늘날까지 이러한 변환(transformations)에 대해서는 침묵을 지키고 있다.
  벌써 이러한 변환을 특정 종류의 애플리케이션에 사용할 엔터티 본문에 적용했을 때 심각한 운영 문제가 발생하였다. 예를 들어 의료 이미지 처리, 과학적 자료 분석 및 end-to-end 인증에 사용되는 애플리케이션은 모두 원서버의 entity-body와 비트 단위까지 동일한 엔터티 본문을 수신하는 방식에 의존하고 있다.
  따라서 응답이 no-transform 지시자를 포함하고 있으면 가장 가까운 캐시나 프락시는 13.5.2 절에 열거된 이러한 헤더들은 no-transform 지시자에 종속적이기 때문에 이들을 절대로 변경해서는 안 된다. 이것은 캐시 또는 프락시는 이러한 헤더가 명시한 어떠한 측면의 entity-body도 변경하지 말아야 한다는 것을 의미한다. 
  

14.9.6. 캐시 제어 확장 
Cache-Control 헤더 필드는 하나 또는 그 이상의 cache-extension 토큰을 이용하여 각각 선택적으로 부여된 값을 가지고 확장할 수 있다. 정보 확장(Informational extensions - 캐시 행태에 변화를 요구하지 않는)은 다른 지시자의 의미를 변화시키지 않고도 추가할 수 있다. 행태 확장(behavioral extensions)은 캐시 지시자의 기본 베이스에 대한 변경자의 역할을 수행하도록 디자인되었다. 새로운 지시자 및 표준 지시자 모두가 제공되어 새로운 지시자를 이해하지 못하는 애플리케이션은 표준 지시자가 명시한 행태에 기본적으로 따르며 새로운 지시자를 이해하는 애플리케이션은 이를 표준 지시자와 관련된 필요 조건의 변경으로 인식한다. 이러한 방식으로 지시자를 기본 규약에 대한 변경을 요구하지 않고도 확장할 수 있다. 

확장 메커니즘은 원초 HTTP 버전에 정의된 모든 지시자와 특정 확장에는 따르지만 이해할 수 없는 모든 지시자를 무시하는 HTTP 캐시에 달려 있다. 

예를 들어 "private" 지시자의 변경자 역할을 수행하는 "community"로 불리는 가설의 새로운 응답 지시자를 가정하자. 우리는 새로운 지시자를 모든 비 공유 캐시에 대한 추가로 값 내에 이름이 등록된 공동체 구성원만이 공유하는 응답에 대한 캐시를 의미하는 것으로 규정한다. "UCI" community를 공유된 캐시의 private 응답에 사용하길 원하는 원서버는 다음을 포함하여 이를 수행할 수 있다. 

Cache-Control: private, community="UCI"

        
이 헤더 필드를 만난 캐시는 캐시가 "community" cache-extension을 이해할 수 없더라도 "private" 지시자를 보고 이해할 수 있어 안전한 행태의 기본 행태로 전환할 수 있기 때문에 정확하게 작동한다. 

인지할 수 없는 cache-directive는 무시해야 한다. HTTP/1.1캐시가 인지하지 못하는 모든 cache-directive는 캐시가 확장을 이해하지 못하더라도 최소한도로 이러한 캐시 행태가 정확한 것으로 유지되도록 표준 지시자(또는 응답의 기본 캐시 가능성(chchability))와 결합되어 있다고 가정한다. 


14.10. CONNECTION 
Connection 일반 헤더 필드는 발송측이 특정 연결이 원하는 선택 사항을 명시하는 데 사용하며 추가적인 연결 시 프락시를 통하여 통신해서는 절대 안 된다. 

Connection 헤더는 다음과 같은 문법을 가지고 있다. 

Connection-header   =       "Connection" ":" 1#(connection-token)   connection-token    =       token

HTTP/1.1 프락시는 메시지가 전송되기 전에 Connection 헤더를 반드시 분석하여야 하며 이 필드의 각각의 connection-token에 대해 connection-token과 동일한 이름을 가진 메시지에서 모든 헤더 필드를 삭제해야 한다. Connection 선택 사항은 해당 연결 선택 사항과 관련된 파라미터가 없으면 추가적인 헤더 필드가 발송되지 않기 때문에 관련 추가 헤더 필드가 아닌 Connection 헤더 필드에 connection-token의 존재로 알 수 있다. 

HTTP/1.1 은 "close" 연결 선택 사항을 송신측이 응답을 완전히 받은 후에 연결이 종료된다는 것을 표시하는 데 사용한다. 예를 들어, 

Connection: close

위와 같이 close 옵션이 요구나 응답 헤더 필드에 있으면 연결이 현재 의 요구/응답에 완성된 후에 'persistent' (8.1 절)로 간주되어서는 안 된다는 것을 표시한다. 

persistent 연결을 지원하지 않는 HTTP/1.1 응용은 반드시 모든 메시지에 "close" 연결 선택 사항을 포함하고 있어야 한다. 


14.11. CONTENT-ENCODING 
Content-Encoding entity-header 필드는 entity-body에 대한 변경자로 사용한다. 이것이 있으면 그 값은 entity-body에 어떠한 추가 Content coding이 적용되었는지 표시하여 Content-Type 헤더 필드가 참조하는 media-type을 얻기 위하여 어떠한 디코딩 메커니즘을 적용해야 하는지 표시한다. Content-Encoding은 주로 문서를 기저의 media type의 정체(identity)를 상실하지 않고도 압축할 수 있도록 하는 데 사용한다. 

Content-Encoding  = "Content-Encoding" ":" 1#content-coding #

Content 코딩은 3.5절에 규정되어 있다. 이의 사용 예는, 

Content-Encoding: gzip

          
Content-Encoding은 Request-URI가 식별하는 엔터티의 특징이다. 전형적으로 entity-body는 이 인코딩에 저장되며 표시 또는 유추 목적으로 사용하기 전에만 해독할 수 있다. 
엔터티에 복수의 인코딩을 적용했으면 내용 코딩은 적용된 순서로 열거해야 한다. 
인코딩 파라미터에 관한 추가 정보는 이 규격에서 규정하지 않은 entity-header 필드에서 제공한다. 


14.12. CONTENT-LANGUAGE 
Content-Language entity-header 필드는 포함하고 있는 엔터티 대상 청중자의 자연적인 언어를 기술하고 있다. Entity-body내에서 사용된 모든 언어와 동등하지 않을 수도 있다는 점에 주의 한다. 

Content-Language  = "Content-Language" ":" 1#language-tag

Language 태그는 3.10절에 정의되어 있다. Content-Language의 주된 목적은 사용자가 사용자 자신이 선호하는 언어에 따라 엔터티를 식별하거나 구별할 수 있도록 하는 것이다. 따라서 본문 내용이 덴마크어를 이해할 수 있는 청중을 위한 것이라면 적절한 필드는 다음과 같다. 

Content-Language: da

      
Content-Language가 명시되어 있지 않으면 기본은 내용이 모든 언어의 청중을 위한 것이다. 이는 송신측이 이것이 특정 자연적 언어에 한정적인 것이 아니거나 사용하고 하는 언어를 알 수 없다는 것을 의미한다. 
복수 언어는 복수의 청중을 위한 내용을 열거할 수 있다. 예를 들어 "Treaty of Waitangi,"의 번역을 마오리(Maori)어 버전 및 영어 버전으로 번역하려면, 

Content-Language: mi, en

        
그러나 엔터티에 복수의 언어가 존재한다는 것이 여러 언어를 사용할 수 있는 청중을 위한 것을 의미하는 것은 아니다. 이의 예는 "A First Lesson in Latin" 과 같은 초급자 언어 입문서이다. 이는 분명히 영어를 사용하는 청중을 위한 것이다. 이 경우 Content-Language는 "en"만을 포함해야 한다. 

Content-Language는 모든 media type에 적용할 수 있고 텍스트 문서에 한정된 것은 아니다. 


14.13. CONTENT-LENGTH 
Content-Length entity-header 필드는 message-body의 크기를 수신측에 발송된 octets의 십진수, HEAD method의 경우에는 요구가 GET이었을 경우 발송되었을 entity-body의 크기를 표시한다. 

Content-Length    = "Content-Length" ":" 1*DIGIT

      
예는, 

Content-Length: 3495

         
애플리케이션은 엔터티의 media type에 관계 없이 이 필드를 전송하는 message-body의 크기를 표시하는 데 사용한다. 수신측이 신뢰성 있게 entity-body를 포함하고 있는HTTP/1.1 요구의 종료를 결정할 수 있어야 한다. 예를 들어 요구가 유효한 Content-Length 필드를 가지고 Transfer-Encoding:chunked 또는multipart body를 사용할 수 있기 때문이다. 
제로보다 크거나 동등한 모든 Content-Length는 유효한 값이다. 4.4절은 Content-Length가 주어지지 않았을 때 message-body의 길이를 결정하는 방법을 기술하고 있다. 
주의: 이 필드의 의미는 해당되는 "message/external-body" content-type에서 사용되는 선택 필드인 MIME 규정과는 상당히 다르다. HTTP에서 메시지의 길이를 전송하기 전에 결정할 수 있으면 언제나 이 필드를 발송해야 한다. 


14.14. CONTENT-LOCATION 
Content-Location entity-header 필드는 메시지에 포함된 엔터티의 자원 위치를 제공하는 데 사용한다. 자원이 자신과 관련된 복수의 엔터티를 가지고 있고 각 엔터티가 사실상 개별적으로 접근하였을 때 구별된 위치를 가지고 있는 경우에는 서버는 리턴되는 특정 변형자(variant)에 대한 Content-Location을 제공해야 한다. 또한 서버는 응답 엔터티에 상응하는 자원의 Content-Location를 제공해야 한다. 

Content-Location      =       "Content-Location" ":"                                               ( absoluteURI | relativeURI )

                
Content-Base 헤더 필드가 없으면 Content-Location 의 값은 엔터티의 URL을 규정한다.(14.11절 참조) 
Content-Location 값은 원래 요청된 URI의 대체물이 아니다. 이것은 요구를 방송한 시점의 특정 엔터티에 상응하는 자원의 위치를 표현하는 것일 뿐이다. 이후의 요구는 해당 특정 엔터티의 자원을 식별하는 것이 목적이라면 Content-Location URI를 사용할 수 있다. 
캐시는 Content-Location을 조회하는 데 사용되는 URI와 다른 Content-Location을 가진 엔터티를 해당 Content-Location URI의 추후 요구에 대한 응답에 사용할 수 있다고 가정해서는 안 된다. 그러나 Content-Location은 13.6절에서 기술한 대로 단일 요청 자원에서 조회한 복수의 엔터티를 차별화하는 데 사용할 수 있다. 

Content-Location이 상대적인 URI이면 응답에서 제공하는 어떠한 Content-Location URI에 상대적인 것으로 해석해야 한다. 아무런 Content-Base도 제공되지 않았으면 상대적인 URI은 Request-URI에 상대적인 것으로 해석해야 한다. 


14.15. CONTENT-MD5 
RFC 1864 [23]에 규정된 바와 같이 entity-body의 end-to-end 메시지 무결성을(end-to-end message integrity check (MIC)) 점검하기 위한 Content-MD5 entity-header 필드는 entity-body의 MD5 digest이다.(주의: MIC는 전송되는 도중의 entity-body에 대한 우발적인 변경을 탐지하는 데 유용하지만 악의적인 공격에 대한 증명은 아니다.) 

Content-MD5   = "Content-MD5" ":" md5-digest   md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>

                          
Content-MD5 헤더 필드는 원서버가 entity-body의 무결성을 확인하는 기능으로서 생성할 수 있다. 원서버만이 Content-MD5 헤더 필드를 생성할 수 있으며 프락시나 게이트웨이는 그 값을 end-to-end  무결성 점검으로 사용하지 못하도록 변질시킬 수 있기 때문에 절대도 이것을 생산하면 안 된다. 프락시나 게이트웨이를 포함한 어떠한 entity-body의 수신측도 이 헤더 필드의 digest value가 수신된 entity-body의 digest value와 일치하는지 점검할 수 있다. 

MD5 digest는 적용된 모든 Content-Encoding을 포함하지만 message-body에 적용되었을 수 있는 모든 Transfer-Encoding은 포함하지 않는 entity-body의 내용에 기초하여 산출할 수 있다. 수신된 메시지에 Transfer-Encoding이 포함되어 있으면 해당 인코딩은 수신된 엔터티에 대한 Content-MD5값을 점검하기 이전에 삭제하여야 한다. 
이것은 digest가 Transfer-Encoding을 적용하지 않고 발송했을 때의 entity-body와 정확하게 동일한 entity-body의 octets에서 산출되는 결과를 초래한다. 

HTTP는 RFC 1864를 확장하여 digest가 MIME 복합 media-type (예를 들어  multipart/* 및 message/rfc822)에서 산출될 수 있도록 허용한다. 그러나 이것이 이전 문장에서 규정한 digest 산출 방법을 변경하지는 않는다. 

주의: 이것은 몇몇 결과를 초래한다. 복합 유형의 entity-Body는 자신의 MIME 및 HTTP 헤더에 복수의 body-parts를 가질 수 있다.( Content-MD5, Content-Transfer-Encoding 및 Content-Encoding 헤더 포함) 만약 body-part 가 Content-Transfer-Encoding 또는 Content-Encoding 헤더를 가지고 있으면 body-part의 내용이 인코딩되었고 body-part가 현재 처럼(예를 들어 적용 이후) Content-MD5 digest에 포함되어 있다고 가정할 수 있다. 

주의: Content-MD5 규정이 RFC 1864의 MIME entity-bodies에서와 규정과 동일하기는 하지만 Content-MD5를 HTTP entity-bodies에 적용하는 것이 MIME entity-bodies에 적용하는 것과 다를 수 있는 몇 가지 경우가 있다. 그 중의 하나가 MIME과는 달리 HTTP는 Content-Transfer-Encoding을 사용하지 않지만 Transfer-Encoding 및 Content-Encoding 을 사용한다는 것이다. 다른 것은 HTTP가 MIME보다 더 자주 이진 내용 유형을 사용하기 때문에 digest를 산출하는 데 사용된 바이트 순서는 해당 유형에 정의된 전송 바이트 순서라는 점에 주의할 필요가 있다. 마지막으로 HTTP가 CRLF로 정규화된 폼뿐만 아니라 어떠한 복수 라인 줄바꿈 관례에 따른 텍스트 유형이든 전송을 허용한다는 것이다. 실제로 전송된 텍스트에 사용된 줄바꿈(line break) 관례는 digest를 산출할 때 변경하지 말아야 한다. 

14.16. CONTENT-RANGE 
Content-Range entity-header는 부분적 entity-body와 함께 전송하여 전체 entity-body 의 어느 부분에 부분적 본문을 삽입해야 하는 가를 명시한다. 또한 이것은 전체 entity-body의 크기를 표시하기도 한다. 서버가 클라이언트에게 부분적 응답을 리턴했을 때 서버는 응답이 차지하는 영역의 범위 및 전체 entity-body의 길이를 기술해야 한다. 

Content-Range                   =       "Content-Range" ":" content-range-spec   content-range-spec            =       byte-content-range-spec   byte-content-range-spec    =       bytes-unit SP first-byte-pos "-"                                                       last-byte-pos "/" entity-length   entity-length                       =       1*DIGIT

         
Byte-ranges-specifier 값과는 달이 byte-content-range-spec은 하나의 영역만을 명시할 수 있으며 영역의 처음 및 마지막 바이트의 절대 위치를 포함하고 있어야 한다. 
Byte-content-range-spec whose Last-byte-pos 값이 first-byte-pos 값보다 적은 byte-content-range-spec이나 entity-length 값이 last-byte-pos 값보다 적거나 동등한 것은 무효이다. 유효하지 않은 byte-content-range-spec의 수신측은 이것과 이에 따라 전송되는 모든 내용을 반드시 무시해야 한다. 

엔터티가 전체 1234 바이트를 포함하고 있다고 가정하면 byte-content-range-spec 값의 예는 다음과 같다. 

• The first 500 bytes:
     bytes 0-499/1234
• The second 500 bytes:
     bytes 500-999/1234
• All except for the first 500 bytes:
     bytes 500-1233/1234
• The last 500 bytes:
     bytes 734-1233/1234

HTTP 메시지가 단일 영역의 내용을 포함하고 있을 때 이 내용은 Content-Range 헤더 및 실제적으로 전송되는 바이트 수를 표시하는 Content-Length 헤더와 함께 전송된다. 예를 들면, 

HTTP/1.1 206 Partial content  Date: Wed, 15 Nov 1995 06:25:24 GMT  Last-modified: Wed, 15 Nov 1995 04:58:08 GMT  Content-Range: bytes 21010-47021/47022  Content-Length: 26012  Content-Type: image/gif

                          
HTTP 메시지가 복수 영역의 내용을 포함하고 있을 때(예를 들어 복수의 중첩되지 않는 영역에 걸친 요구에 대한 응답) 이 영역들은 multipart MIME 메시지로서 전달된다. 이 목적에 사용된 multipart MIME content-type 은 이 규격에서"multipart/byteranges"로 규정하고 있다. 규정에 관하여는 부록 19.2절을 참조한다. 

MIME multipart/byteranges 메시지를 해독할 수 없는 클라이언트는 단일 요구의 복수 byte-ranges를 요청해야 한다. 
클라이언트가 단일 요구에 복수의 byte-ranges를 요청하면 서버는 요구에 나타난 순서 대로 이것들을 되돌려 주어야 한다. 
서버가 byte-range-spec이 무효이기 때문에 무시했으면 서버는 요구를 유효하지 않은 Range 헤더 필드가 존재하지 않는 것처럼 처리해야 한다.(대개의 경우 이것은 전체 엔터티를 포함하고 있는 200 메시지를 리턴함을 의미한다.) 이유는 클라이언트가 이러한 무효 요구를 하는 유일한 시간은 엔터티가 이전 유구에 의해 수신된 엔터티보다 작을 때이기 때문이다. 


14.17. CONTENT-TYPE 
Content-Type entity-header 필드는 수신측에 발송한 entity-body의 media type을 표시하거나, 요구가 GET이었으면 발송되었을 media type를 표시한다. 
          Content-Type   = "Content-Type" ":" media-type 
Media types은 3.7장에 규정되어 있으며 이 필드의 사용 예는 다음과 같다. 
          Content-Type: text/html; charset=ISO-8859-4 
엔터티의 media type을 식별하는 method에 관한 토의는 7.2.1절에 기술되어 있다. 


14.18. DATE 
Date general-header 필드는 메시지가 생성되었을 때의 날짜와 시간을 표시하며 RFC 822의 org-date와 동일한 의미를 가진다. 필드 값은 3.3.1절에 기술된 것처럼 HTTP-date이다. 

Date  = "Date" ":" HTTP-date

  
이의 사용 예는, 

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

사용자 에이전트(요구의 경우)나 원서버(응답의 경우)와 직접적인 접속을 통하여 메시지를 수신하면 날짜는 수신측 끝의 현재 시간인 것으로 가정한다. 그러나 날짜가 캐시 응답을 평가하는 데 중요하기 때문에(원서버가 그렇다고 믿기 때문에) 원서버는 모든 응답에 Date 헤더 필드를 반드시 포함해야 한다. 클라이언트는 PUT 및 POST 요청의 경우처럼 entity-body를 포함하고 있는 메시지의 Date 헤더 필드만을 발송해야 하기는 하지만 선택 사항이기도 하다. Date 헤더 필드를 가지고 있지 않은 수신 메시지는 수신측이 메시지를 캐시하거나 Date를 요구하는 규약을 이용한 게이트웨이를 통과할 때 수신측이 하나를 지정해야 한다. 
이론상으로 날짜는 엔터티가 생성되지 바로 직전 순간을 표시해야 한다. 그러나 실제상으로 날짜는 의미 값에 영향을 미치지 않고 메시지 원문을 생성하는 동안 아무 시간에서나 생성될 수 있다. 
Date의 포맷은 3.3절의 HTTP-date 가 규정하는 절대 날짜 및 시간이다. 반드시 RFC1123 [8]-날짜 포맷으로 발송해야 한다. 


14.19. ETAG 
ETag entity-header 필드는 관련된 엔터티의 엔터티 태그를 정의한다. 엔터티 태그와 함께 사용하는 헤더는 14.20, 14.25, 14.26 및 14.43 절에 기술되어 있다. 엔터티 태그는 동일한 자원(13.3.2절 참조)의 다른 엔터티와 비교하는 데도 사용할 수 있다. 

ETag = "ETag" ":" entity-tag

예: 

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

14.20. EXPECT


14.21. EXPIRES 
Expires entity-header 필드는 그 시간 이후 응답이 낡았다고 간주해야 하는 날짜/날짜를 제공한다. 캐시(프락시 캐시 또는 사용자 에이전트 캐시)는 대개 먼저 원서버(또는 엔터티의 신선한 복사본을 가지고 있는 가장 가까운 캐시)가 검증하지 않는 한 낡은 캐시 엔트리를 리턴하지 않는다. 유효일 모델에 관한 추가 논의는 13.2절을 참조한다. 
Expires 필드가 존재한다는 것이 그 시간 이전 또는 이후에 원래의 자원이 변경되거나 사라진다는 것을 의미하지는 않는다. 
포맷은 3.3절에서 정의한 HTTP-date 절대 날짜와 시간이다. 반드시 RFC1123-date 포맷이어야 한다. 

Expires = "Expires" ":" HTTP-date

         
이의 사용 예는 다음과 같다. 

Expires: Thu, 01 Dec 1994 16:00:00 GMT

         
주의: 응답이 max-age 지시자를 포함한 Cache-Control 필드를 포함하고 있으면 그 지시자는 Expires 필드를 무시한다. 
HTTP/1.1 클라이언트와 캐시는 반드시 다른 유효하지 않는 날짜 포맷을, 특히 "0" 값을 포함하고 있는 날짜 포맷을 지나간 날짜로 취급해야 한다.(예를 들면 "벌써 만료된"으로) 응답을 "벌써 만료된" 것으로 표시하기 위해서 원서버는 Expires 날짜를 Date 헤더 필드와 동일한 것으로 사용해야 한다.(13.2.4절의 유효일 계산 원칙을 참조) 

응답을 "결코 만료되지 않는" 것으로 표시하기 위해서 원서버는 Expires 날짜를 대략 응답이 발송된 후 시점부터 1 년 후를 지정한다. HTTP/1.1 서버는 향후 1년 이상 된 Expires 날짜를 발송하지 말아야 한다. 
기본적으로 캐시할 수 없는 응답에 미래의 특정 시간의 시간 값과 함께 Expires 헤더 필드가 존재하면 Cache-Control 헤더 필드가(14.9절 참조) 다른 식으로 표시하지 않는 한 응답을 캐시할 수 있다는 것을 표시한다. 


14.22. FROM 
From request-header 필드는, 존재한다면, 요청 사용자 에이전트를 통제하는 인간 사용자의 인터넷 전자우편 주소를 포함하고 있어야 한다. 주소는 RFC 822의 우편함 (as updated by RFC 1123에 의하여 갱신된 것처럼)이 규정한 것처럼 기계가 사용할 수 있는 것이어야 한다. 

From   = "From" ":" mailbox

사용 예는, 

From: webmaster@w3.org

          
이 헤더 필드는 로깅(logging) 목적이나 무효이거나 원하지 않는 요구의 출처를 확인하는 수단으로 사용할 수 있다. 접속 금지의 불확실한 폼으로 사용해서는 안 된다. 이 필드는 요구가 주어진 사람(수행된 method에 대한 책임을 지는 사람)을 대신하여 수행되고 있는 것으로 해석한다. 특히 로봇 에이전트는 이 헤더를 포함하여 수신측 끝에서 문제가 발생하였을 때 로봇을 운영하는 책임을 진 사람과 연락할 수 있도록 해야 한다. 
이 필드의 인터넷 전자우편 주소는 요구를 발송한 인터넷 호스트와 구별될 수 있다. 예를 들어 요구가 프락시를 통과할 경우 원서버의 주소를 사용할 수 있다. 
주의: 클라이언트는 사용자의 동의 없이는 그것이 사용자의 사생활 보호나 사이트의 보안 정책과 충돌할 수 있기 때문에 From 헤더 필드를 발송해서는 안 된다. 사용자는 요구를 발송하기 전 어떤 시점에라도 이 필드의 값을 무력화, 활성화 및 변경할 수 있도록 할 것을 강력히 추천한다. 


14.23. HOST 
Host request-header 필드는 사용자나 참조하고자 하는 자원(보통 3.2.2 절에 기술한 HTTP URL)이 부여한 원래의 URL에서 얻은 대로 요구 받고 있는 자원의 인터넷 호스트와 포트 숫자를 명시한다. Host 필드 값은 반드시 원서버나 원래의 URL이 부여한 게이트웨이 네트워크 위치를 표시해야 한다. 이것은 원서버나 게이트웨이가 단일 IP 주소의 복수 호스트 이름에 사용되는 호스트의 루트 "/" URL과 같이 내부적으로 모호한 URL을 구별할 수 있도록 한다. 
          Host = "Host" ":" host [ ":" port ]    ; 섹션3.2.2 
뒤 따르는 포트 정보가 없는 "호스트"는 요구된 서비스의 기본 포트를 의미한다.(HTTP URL의 "80"). 예를 들어 원서버의 <http://www.w3.org/pub/WWW/>에 대한 요청은 반드시 다음을 포함해야 한다. 
          GET /pub/WWW/ HTTP/1.1 
          Host: www.w3.org 
클라이언트는 인터넷 상의 모든 HTTP/1.1 요구 메시지에 Host 헤더 필드를 반드시 포함해야 한다. 기존에 Host 필드가 존재하지 않으면 HTTP/1.1 프락시는 요구를 인터넷 상에서 전송하기 전에 요구 메시지에 Host 필드를 반드시 추가해야 한다. 인터넷을 기반을 둔 모든 HTTP/1.1 서버는 Host 헤더 필드가 없는 모든 HTTP/1.1 요구 메시지에 대하여 400 상태 코드로 반드시 응답해야 한다. 
Host와 관련된 다른 필요 조건 사항에 대해서는 5.2 및 19.5.1 절을 참조한다. 


14.24. IF-MODIFIED-SINCE 
If-Modified-Since request-header 필드는 GET method와 함께 사용하여 GET method를 조건적으로 만든다. 요구된 변형자가 이 필드에 명시된 시간 이후에 변경되지 않았으면 엔터티는 서버로부터 리턴 되지 않는다. 대신 304 (not modified) 응답이 message-body없이 리턴 될 것이다. 
          If-Modified-Since = "If-Modified-Since" ":" HTTP-date 
이 필드의 사용 예는, 
          If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 
If-Modified-Since 헤더는 있지만 Range 헤더가 없는 GET method는 식별된 엔터티가 If-Modified-Since 헤더에 표시된 날짜 이후로 변경되었을 때만 전송되도록 요구한다. 이것을 결정하는 알고리즘은 다음 경우의 수를 포함한다, 
a)      요청이 보통 200(OK) 상태 이외의 것을 산출하거나 전달된 If-Modified-Since 날짜가 무효이면 응답은 일반적인 GET와 완전히 동일하다. 서버의 현재 시간보다 이후인 날짜는 유효하지 않다. 
b)      변형자가 If-Modified-Since 날짜 이후에 변경되었으면 응답은 일반적인 GET와 완전히 동일하다. 
c)      변형자가 유효한 If-Modified-Since 날짜 이후 변경되지 않았으면 서버는 반드시 304 (Not Modified) 응답을 리턴해야 한다. 
이 기능의 목적은 트랜잭션 오버헤드(transaction overhead)를 최소화하면서 캐시된 정보를 효과적으로 갱신할 수 있도록 하는 것이다.
Range request-header 필드는 If-Modified-Since의 의미를 변경한다는 점에 주의한다. 전체적인 내용은14.36절을 참조한다. 
클라이언트와 동시화되지 않은 시계를 가진 서버가 If-Modified-Since 시간을 해석할 수 있음을 주의해야 한다. 
클라이언트가 동일한 요구에서 If-Modified-Since 헤더를 가져 오는 대신 If-Modified-Since 헤더에 자의적인 날짜를 사용하였으면 클라이언트는 이 날짜가 서버의 시간 해석 방식에 의해 해석된다는 사실을 인지해야만 한다는 것에 주의해야 한다. 클라이언트는 동시화되지 않는 시계 및 클라이언트와 서버의 사이의 각기 다른 시간 인코딩으로 인한 반올림을 고려해야 한다. 이것은 처음 요구한 시간과 계속되는 요구의 If-Modified-Since 날짜 사이에서 문서가 변경되었을 경우 경쟁 상황(race conditions)이 발생할 가능성 및 If-Modified-Since 날짜를 클라이언트의 시계에서 서버 시계와 연결 없이 추출하였을 경우 틀린 시계와 관련된(clock-skew-related) 문제가 발생할 가능성을 모두 포함한다. 클라이언트와 서버 사이의 틀린 시간의 교정은 기껏해야 네트웍의 잠복기(network latency) 때문에 근사치일 뿐이다. 


14.25. IF-MATCH 
If-Match request-header 필드는 method와 함께 사용하여 method를 조건적으로 만든다. 이전에 자원에서 획득한 하나 또는 그 이상의 엔터티를 가진 클라이언트는 연관된 엔터티 태그의 목록을 If-Match 헤더 필드에 포함하여 이러한 엔터티 중의 하나가 현재의 것임을 증명할 수 있다. 이 기능의 목적은 트랜잭션 오버헤드(transaction overhead)를 최소화하면서 캐시된 정보를 효과적으로 갱신할 수 있도록 하는 것이다. 또한 요구를 갱신할 때 자원의 잘못된 버전에 대한 부주의한 변경을 방지하는 데 사용할 수 있다. 특별한 경우로 "*" 값은 자원의 모든 현재 엔터티와 일치한다. 
          If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) 
해당 자원에 유사한GET 요구(If-Match 헤더 없이)에 대한 응답으로 리턴되었을 수 있는 엔터티의 엔터티 태그와 일치하는 어떠한 엔터티 태그나 "*"이 주어지고 해당 자원에 대한 현재 의 엔터티가 존재한다면 서버는 If-Match 헤더 필드가 존재하지 않는 것처럼 요구 받은 method를 수행할 것이다. 
서버는 If-Match의 엔터티 태그를 비교하기 위하여 반드시 강한 비교 기능(strong comparison function (3.11 절 참조))을 사용해야 한다. 
아무런 엔터티 태그도 일치하지 않거나 "*" 이 주어졌는데도 아무런 현재의 엔터티가 존재하지 않으면 서버는 요구 받은 method를 절대 수행해서는 안되고 반드시 412 (Precondition Failed) 응답을 리턴해야 한다. 이 행태는 클라이언트가 PUT과 같은 갱신 method가 클라이언트가 마지막으로 조회한 이후 변경된 자원을 다시 변경하지 못하도록 한다. 
If-Match 헤더 필드 없이 요구가 2xx 상태 이외의 어떤 것이라도 초래하게 되면 If-Match를 무시해야 한다. 
"If-Match: *" 의 의미는 원서버(또는 Vary 메커니즘을 이용한 캐시, 14.43절 참조)가 선택한 표시 방법이 존재하면 method를 반드시 수행해야 하고 그렇지 않다면 절대 수행해서는 안 된다는 것이다. 
자원을 갱신할 목적의 요구(예를 들어 PUT)는 If-Match값(단일 엔터티 태그)에 상응하는 엔터티가 더 이상 해당 자원을 표시하는 않는다면 요구 method를 절대로 적용해서는 안 된다는 것을 표시하기 위하여 If-Match 헤더 필드를 포함할 수 있다. 이것은 사용자가 자신이 인지하지 못하는 동안 자원이 변경되었으면 요구가 완료되는 것을 바라지 않음을 표시할 수 있도록 한다. 
예를 들면, 
          If-Match: "xyzzy" 
          If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 
          If-Match: * 


14.26. IF-NONE-MATCH 
If-None-Match request-header 필드는 method와 함께 사용하여 method를 조건적으로 만든다. 이전에 자원에서 획득한 하나 또는 그 이상의 엔터티를 가진 클라이언트는 연관된 엔터티 태그의 목록을 If-None-Match 헤더 필드에 포함하여 이러한 엔터티 중의 하나가 현재의 것임을 증명할 수 있다. 이 기능의 목적은 트랜잭션 오버헤드(transaction overhead)를 최소화하면서 캐시된 정보를 효과적으로 갱신할 수 있도록 하는 것이다. 또한 요구를 갱신할 때 자원의 잘못된 버전에 대한 부주의한 변경을 방지하는 데 사용할 수 있다. 
특별한 경우로 "*" 값은 자원의 모든 현재 엔터티와 일치한다. 
          If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) 
해당 자원에 유사한GET 요구(If-Match 헤더 없이)에 대한 응답으로 리턴되었을 수 있는 엔터티의 엔터티 태그와 일치하는 어떠한 엔터티 태그나 "*"이 주어지고 해당 자원에 대한 현재의 엔터티가 존재한다면 서버는 요구 받은 method를 절대로 수행해서는 안 된다. 대신 요구 method가 GET 또는 HEAD이면 서버는 일치하는 엔터티 중 하나의 캐시와 관련된 entity-header 필드(특히 ETag)를 포함하여 304 (Not Modified) 응답으로 응해야 한다. 다른 모든 요구 method에 대해서 서버는 상태 412(Precondition Failed)로 응답해야 한다. 
두 엔터티 태그가 일치하는지 결정하는 원칙에 대하여는 13.3.3절을 참조한다. GET 또는 HEAD 요구에는 약한 비교 기능(weak comparison function )만을 사용할 수 있다. 
어떠한 엔터티 태그도 일치하지 않고 "*"이 주어지고 해당 자원에 대한 아무런 현재 엔터티도 존재하지 않는다면 서버는 If-None-Match 헤더 필드가 존재하지 않는 것처럼 요구 받은 method를 수행할 것이다. 
If-None-Match 헤더 필드 없이 요구가 2xx 상태 이외의 어떤 것이라도 초래하게 되면 If-None-Match를 무시해야 한다. 
" If-None-Match: *" 의 의미는 원서버(또는 Vary 메커니즘을 이용한 캐시, 14.43절 참조)가 선택한 표시 방법이 존재하면 method를 반드시 수행해야 하고 그렇지 않다면 절대 수행해서는 안 된다는 것이다. 이 기능은 PUT 처리 시 경쟁(race)을 방지하는 데 유용하다. 
   예: 

          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: * 


14.27. IF-RANGE 
클라이언트가 자신의 캐시에 엔터티의 부분적 사본을 가지고 있고 전체 엔터티의 최신 갱신 사본을 가지고 싶다면 조건적인 GET(If-Unmodified-Since 및 If-Match 중 하나나 둘 모두를 이용하여)의 Range request-header를 사용할 수 있다. 그러나 엔터티가 변경되어 조건이 실패한다면 클라이언트는 현재의 전체 entity-body를 획득하기 위해 2차 요구를 할 수 있다. 
If-Range 헤더는 클라이언트가 2차 요구를 "단축(short-circuit)"할 수 있도록 한다. 약식으로 말하면 이것의 의미는 `엔터티가 변경되지 않았다면 내가 빠트린 부분만을 발송하고 그렇지 않다면 새로운 전체 엔터티를 발송하시오. '이다. 
           If-Range = "If-Range" ":" ( entity-tag | HTTP-date ) 
클라이언트가 엔터티의 엔터티 태그를 가지고 있지 않으나 Last-Modified 날짜를 가지고 있으면 클라이언트는 그 날짜를 If-Range 헤더에서 사용할 수 있다. (서버는 2 문자 이내를 검사하여 유효한 HTTP-date와 entity-tage의 어떠한 폼도 구별할 수 있다.) If-Range 헤더는 Range 헤더와 함께만 사용할 수 있으며, Range 헤더를 포함하고 있지 않거나 서버가 하부-영역 운영(sub-range operation)을 지원하지 않으면 요구를 반드시 무시해야 한다. 
If-Range 내의 엔터티 태그가 엔터티의 현재 엔터티 태그와 일치하면 서버는 206 (Partial content)응답을 이용하여 자세한 엔터티의 하부-영역을 제공해야만 한다. 엔터티 태그가 일치하지 않으면 서버는 200 (OK) 응답을 이용하여 전체 엔터티를 리턴해야 한다. 


14.28. IF-UNMODIFIED-SINCE 
If-Unmodified-Since request-header 필드는 method와 함께 사용하여 method를 조건적으로 만든다. 요구된 자원이 이 필드에 명시된 시간 이후 변경되지 않았으면 서버는 If-Unmodified-Since 헤더가 존재하지 않는 것처럼 요구 받은 작업을 수행해야 한다. 
요구 받은 변형자가 지정된 시간 이후에 변경되었으면 서버는 요구 받은 작업을 절대로 수행해서는 안 되며 반드시 412 (Precondition Failed)를 리턴해야 한다. 
         If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date 
이 필드의 사용 예는, 
          If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 
요구가 대개(예를 들어 If-Unmodified-Since 헤더 없이) 2xx 상태 이외의 어떤 것이라도 초래하게 되면 If-Unmodified-Since를 무시해야 한다. 
명시한 날짜가 유효하지 않으면 헤더를 무시해야 한다. 


14.29. LAST-MODIFIED 
Last-Modified entity-header 필드는 원서버가 변형자가 마지막으로 변경되었다고 믿는 날짜와 시간을 표시한다. 
          Last-Modified  = "Last-Modified" ":" HTTP-date 
사용 예는, 
          Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 
이 헤더 필드의 정확한 의미는 원서버의 구현 방식 및 원래 자원의 성격에 따라 달라진다. 파일의 경우 의미는 파일 시스템에서 마지막으로 변경된 시간을 역동적으로 부분을 포함하는 엔터티의 경우 의미는 부분 요소가 마지막으로 변경된 시간 세트가 될 수 있다. 데이터 베이스 게이트웨이의 경우에는 레코드의 최근 갱신 시간 스탬프(stamp)를 , 가상 객체의 경우에는 내부 상태가 마지막으로 변경된 시간일 수 있다. 
원서버는 절대 서버의 메시지 발생 시간보다 늦은 Last-Modified 날자를 발송해서는 안 된다. 이처럼 자원의 최근 변경이 미래의 특정 시간을 표시하는 경우 서버는 그 날짜를 메시지 발생 날짜로 대체해야 한다. 
기본 서버는 엔터티의 Last-Modified 값을 응답의 Date 값을 생성한 시간과 가능한 한 가까운 것을 얻어야 한다. 이것은 수신측이 특히 엔터티가 응답이 생성된 시간에 가깝게 변경되었을 때 정확하게 엔터티의 변경 시간을 평가할 수 있도록 한다. 
HTTP/1.1 서버는 가능할 때 마다 반드시 Last-Modified를 발송해야 한다. 


14.30. LOCATION 
Location response-header 필드는 요구의 완성 또는 새로운 자원의 식별을 위해 수신측의 방향을 Request-URI 가 아닌 다른 장소로 방향을 재설정하는 데 사용한다. 201 (Created) 응답의 경우 Location 은 요구에 의해 새롭게 생성된 자원의 위치이다. 3xx 응답의 경우 위치는 자원의 자동 방향 재설정을 위해 서버가 선호하는 URL을 표시한다. 
          Location       = "Location" ":" absoluteURI 
예는, 
          Location: http://www.w3.org/pub/WWW/People.html 
주의: Content-Location 헤더 필드(14.15절)는 Content-Location이 요구에 포함된 엔터티의 원래 위치를 식별한다는 점에서 Location과 다르다. 따라서 응답이 Location 및 Content-Location 헤더 필드를 모두 포함할 수 있다. 몇몇 methods의 캐시 필요 조건에 관해서는 13.10 절을 참조한다. 


14.31. MAX-FORWARDS 
Max-Forwards request-header 필드는 TRACE method (14.31 절)와 함께 사용하여 다음의 들어오는 방향(inbound)의 서버에 요구를 전달할 수 있는 프락시나 게이트웨이의 숫자를 제한한다. 
          Max-Forwards   = "Max-Forwards" ":" 1*DIGIT 
Max-Forwards 값은 이 요구 메시지가 전달될 수 있는 남은 횟수를 표시하는 십진수 정수이다. 
Max-Forwards 헤더 필드를 포함하고 있는 TRACE 요구를 수신하는 각각의 프락시나 게이트웨이는 요구를 전달하지 이전에 그 값을 점검하고 갱신해야만 한다. 수신된 값이 제로(0)이면 수신측은 요구를 전달해서는 안 되며 대신 수신한 요구 메시지를 응답 entity-body(9.8 절에 기술한 바와 같이)로서 포함하는 200 (OK) 응답으로 마지막 수신측의 입장에서 응답해야 한다. 수신한 Max-Forwards 값이 제로보다 크면 전달된 메시지는 값이 1만큼 감소된 갱신된 Max-Forwards 필드를 포함해야 한다. 
Max-Forwards 헤더 필드는 이 규격에서 정의한 다른 모든 method 및 해당 method 정의의 일 부분으로 명백하게 참조되지 않는 모든 확장 method에서는 무시되어야 한다. 


14.32. PRAGMA 
Pragma general-header 필드는 request/response chain을 따라 어떤 수신측에도 적용할 수 있는 구현 방식에 한정된 지시자(implementation-specific)를 포함하는 데 사용한다. 모든 pragma 지시자는 규약의 관점에서 선택 사항적 행태를 명시한다. 그러나 몇몇 시스템은 그 행태가 지시자와 일치할 것을 요구한다. 
          Pragma                =       "Pragma" ":" 1#pragma-directive 
          pragma-directive      =       "no-cache" | extension-pragma 
          extension-pragma      =       token [ "=" ( token | quoted-string ) ] 
No-cache 지시자가 요구 메시지에 존재하면 애플리케이션은 요구되고 있는 것의 캐시 사본을 가지고 있다 하더라도 요구를 원서버에 전달해야 한다. 이 pragma 지시자는 no-cache cache-directive (14.9 절 참조)와 동일한 의미를 가지며 여기서는 HTTP/1.0과의 호환성 유지를 위해 규정하였다. 클라이언트는 No-cache 요구가 HTTP/1.1을 따르지 않는 것으로 알려진 서버로 전달되었을 때 두 헤더 필드를 모두 포함해야 한다. 
Pragma 지시자는 애플리케이션에서 가지는 중요도에 관계없이 지시자는 request/response chain을 따라 모든 수신측에 적용할 수 있기 때문에 반드시 프락시나 게이트웨이 애플리케이션을 통과해야 한다. 
HTTP/1.1 클라이언트는 Pragma request-header를 발송해서는 안 된다. HTTP/1.1 캐시는 "Pragma: no-cache"를 클라이언트가 "Cache-Control: no-cache"를 발송한 것처럼 취급해야 한다. 더 이상의 새로운 Pragma 지시자는 HTTP에 규정되지 않을 것이다. 


14.33. PROXY-AUTHENTICATE 
Proxy-Authenticate response-header 필드는 407 (Proxy Authentication Required) 응답의 일 부분으로 반드시 포함해야 한다. 필드 값은 Request-URI의 프락시에 적용할 수 있는 인증 scheme이나 파라미터를 표시하는 인증 획득 시도로 구성되어 있다. 
          Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge 
HTTP 접근 인증 처리는 11장에 기술되어 있다. WWW-Authenticate와는 달리 Proxy-Authenticate 헤더 필드는 현재의 접속에만 적용되며 다운스트림(downstream) 클라이언트로 전달해서는 안 된다. 그러나 가장 가까운 프락시는 다운스트림(downstream) 클라이언트에 요청하여 자신의 증명서를 획득할 필요가 있을 수 있다. 어떤 상황에서는 프락시가 헤더 필드를 전송하는 것처럼 보일 것이다. 


14.34. PROXY-AUTHORIZATION 
Proxy-Authorization request-header 필드는 클라이언트가 인증을 요구하는 프락시 자신(또는 자신의 사용자)을 식별시킨다. Proxy-Authorization 필드 값은 프락시 및/또는 요청되고 있는 자원의 영역에 관한 사용 에이전트의 인증 획득 정보를 포함하고 있는 증명서로 구성되어 있다. 
       Proxy-Authorization     = "Proxy-Authorization" ":" credentials 
HTTP 접근 인증 획득 절차는 11 장에 기술되어 있다. Authorization와는 달리  Proxy-Authorization 헤더 필드는 Proxy-Authenticate 필드를 이용한 인증 획득을 요구하는 다음의 외부로 향한(outbound) 프락시에만 적용된다. Chain에서 복수의 프락시가 사용되었을 때 Proxy-Authorization 헤더 필드는 보증서를 수신할 예정인 외부로 향한 첫 프락시에 의해 사용된다. 프락시는 그것이 프락시가 주어진 요구를 상호 협조적으로 인증하는 메커니즘이라면 보증서를 클라이언트 요구에서 다음 프락시로 중계할 수 있다. 


14.35. PUBLIC 
Public response-header 필드는 서버가 지원하는 methods 세트를 열거한다. 이 필드의 목적은 엄격하게 수신측에 이례적인 methods에 관한 서버의 능력을 알리는 데 있다. 
열거된 method는 Request-URI에 적용할 수 도 할 수 없을 수도 있다. Allow 헤더 필드(14.7절)는 특정 URI에 사용할 수 있는 method를 표시하는 데 사용한다. 
          Public         = "Public" ":" 1#method 
사용 예는, 
          Public: OPTIONS, MGET, MHEAD, GET, HEAD 
이 헤더 필드는 클라이언트(예를 들어 연결 고리의 가장 가까운 이웃)에 직접적으로 접속된 서버에만 적용된다. 응답이 프락시를 통과한다면 프락시는 Public 헤더 필드를 삭제하든지 자신의 능력에 적용할 수 있는 것으로 대체해야 한다. 


14.36. RANGE 
14.36.1.    BYTE RANGES 
모든 HTTP 엔터티는 연속적인 바이트로서 HTTP 메시지 내에 표현되기 때문에 바이트 범위의 개념은 모든 HTTP 엔터티에 의미가 있다.(그러나 모든 클라이언트나 서버가 byte-range 작업을 지원할 필요는 없다.) 
HTTP 내의 바이트 영역 규격은 entity-body(반드시 message-body와 동일할 필요는 없다.) 내의 바이트 연속에 적용된다. 
바이트 영역 작업은 단일 바이트 영역이나 단일 엔터티 내의 영역 세트를 명시할 수 있다. 
       ranges-specifier         = byte-ranges-specifier 
       byte-ranges-specifier = bytes-unit "=" byte-range-set 
       byte-range-set   = 1#( byte-range-spec | suffix-byte-range-spec ) 
       byte-range-spec          = first-byte-pos "-" [last-byte-pos] 
       first-byte-pos           = 1*DIGIT 
       last-byte-pos            = 1*DIGIT 
Byte-range-spec의 first-byte-pos 값은 영역에서 첫 바이트의 byte-offset을 제공한다. Last-byte-pos 값은 영역에서 마지막 바이트의 byte-offset을 제공한다. 말하자면 명시된 바이트 위치는 포괄적인 것이다. 바이트 오프셋(byte offsets)은 0부터 시작한다. 
Last-byte-pos 값이 존재하면 해당byte-range-spec의 first-byte-pos보다 크거나 같아야 한다. 그렇지 않으면 byte-range-spec은 유효하지 않다. 유효하지 않는 byte-range-spec의 수신측은 이를 무시해야 한다. 
Last-byte-pos 값이 없거나 entity-body의 현재 길이보다 크거나 같으면 last-byte-pos 은 바이트 단위로 entity-body의 현재 길이보다 작은 것과 동일한 것을 사용해야 한다. 
클라이언트는 last-byte-pos 선택을 통하여 엔터티의 크기를 모른 채 수신한 바이트의 숫자를 제한할 수 있다. 
          suffix-byte-range-spec = "-" suffix-length 
          suffix-length = 1*DIGIT 
Suffix-byte-range-spec은 suffix-length 값이 부여한 길이의 entity-body 접미사를 명시하는 데 사용한다.(말하자면 이 폼이 entity-body의 마지막 N 바이트를 명시한다.) 엔터티가 명시된 suffix-length보다 짧으면 전체 entity-body가 사용된다. 
Byte-ranges-specifier 값의 사용 예이다.(entity-body 의 길이가 10000이라고 가정했을 때) 
l     첫 500 바이트 (byte offsets 0-499, inclusive): 
          bytes=0-499 
l     두 번째 500 바이트 (byte offsets 500-999, inclusive): 
          bytes=500-999 
l     마지막 500 바이트(byte offsets 9500-9999, inclusive): 
          bytes=-500 
l     또는 
          bytes=9500- 
l     처음과 마지막 바이트만(bytes 0 and 9999): 
          bytes=0-0,-1 
l     규범적이지는 않지만 유효한 두 번째 500 바이트 명시 (byte offsets 500-999, inclusive): 
          bytes=500-600,601-999 
          bytes=500-700,601-999 

14.36.2.    RANGE RETRIEVAL REQUESTS 
조건적 또는 무조건적 GET method를 이용하는 HTTP 조회 요구는 Range 요구 헤더를 이용하여 요구의 결과로 리턴되는 엔터티에 적용할 수 있는 전체 엔터티 대신 하나 또는 그 이상의 엔터티의 하부 영역을 요청할 수 있다. 
         Range = "Range" ":" ranges-specifier 
서버는 Range 헤더를 무시할 수 있다. 그러나 HTTP/1.1 원서버 및 가장 가까운 캐시는 Range가 부분적으로 실패한 전송을 효과적으로 복구하고 큰 엔터티의 효과적인 부분적 조회를 지원하기 때문에 가능하면 바이트 영역을 지원해야 한다. 
서버가 Range 헤더를 지원하고 명시된 영역 이나 영역들이 엔터티에 적합하다면: 
l     무조건적인 GET에 Range 헤더가 있으면 GET이 성공했을 때 리턴되는 것을 변경한다. 달리 표현하면 응답은 상태 코드 200 (OK) 대신에 206 (Partial Content)을 가지고 온다. 
l     조건적인 GET(If-Modified-Since 및 If-None-Match 중 하나나 둘 모두, 또는If-Unmodified-Since 및 If-Match 중 하나나 둘 모두를 이용하는 요구)에 Range 헤더가 있으면 GET이 성공하고 조건이 참일 때 리턴되는 것을 변경한다. 이것은 조건이 거짓일 경우 리턴되는 304 (Not Modified) 응답에 영향을 미치지 않는다. 
어떤 경우에는 Range 헤더에 첨가형 If-Range 헤더(14.27 절 참조)를 사용하는 것이 더 적절할 수도 있다. 
Range를 지원하는 프락시가 Range 요구를 수신하고 안으로 향하는(inbound) 서버에 요구를 전달하고 이의 응답으로 전체 엔터티를 수신하면 프락시는 클라이언트에게 요구 받은 영역만을 리턴해야 한다. 프락시는 그것이 캐시 할당 정책과 부합된다면 전체 수신 응답을 자신의 캐시에 저장해야 한다. 


14.37. REFERER 
Referer[sic] request-header 필드는 클라이언트가 서버를 위해 Request-URI를 얻은("referrer", 헤더 필드의 스펠링이 틀렸다.) 자원의 주소(URI)를 명시하는 데 사용한다. Referer request-header는 서버가 취미, 로깅 또는 최적화된 캐시 등의 목적으로 자원에 대한 back-links 목록을 생성할 수 있도록 한다. 또는 폐기되었거나 타이핑을 잘못한 링크를 유지관리하기 위해 추적할 수 있도록 한다. Referer 필드는 사용자 키보드에서의 입력 등 자신의 URI를 가지고 있지 않는 출처에서 얻은 Request-URI를 절대로 발송해서는 안 된다. 
        Referer        = "Referer" ":" ( absoluteURI | relativeURI ) 
예: 
        Referer: http://www.w3.org/hypertext/DataSources/Overview.html 
필드 값이 부분적 URI이면 값을 Request-URI에 상대적으로 해석해야 한다. URI는 절대로 파편을 포함해서는 안 된다. 
주의: 링크의 출처가 개인적인 정보이거나 개인적인 정보 출처를 누설할 수 있기 때문에 사용자는 Referer 필드를 발송할 것인지 여부를 선택할 수 있도록 할 것을 강력하게 추천한다. 예를 들어 브라우저 클라이언트는 공개/무명 브라우징(browsing)의 토글 스위치(toggle switch)를 가질 수 있으며 이는 각각 Referer 및 From 정보의 발송을 확성화/무력화한다. 


14.38. RETRY-AFTER 
Retry-After response-header 필드는 503 (Service Unavailable) 응답과 함께 사용하여 요청하는 클라이언트에게 얼마나 오랫동안 서비스를 사용할 수 있는지 표시할 수 있다. 이 필드의 값은 응답 시간 이후의 HTTP-date 또는 초의 정수(십진수)가 될 수 있다. 
          Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds ) 
사용의 두 예는, 
          Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 
          Retry-After: 120 
후자의 예에서 지연시간은 2 분이다. 


14.39. SERVER 
Server response-header 필드는 요구를 처리하는 원서버가 사용하는 소프트웨어에 관한 정보를 포함하고 있다. 이 필드는 서버와 중요한 하부 제품을 식별하는 복수의 제품 토큰(3.8 절) 및 주석을 포함하고 있다. 제품 토큰은 애플리케이션을 식별하는 중요도의 순서에 따라 열거되어 있다. 
          Server         = "Server" ":" 1*( product | comment ) 
예: 
          Server: CERN/3.0 libwww/2.17 
응답이 프락시를 통하여 전달된다면 프락시 애플리케이션은 절대 Server response-header를 변경해서는 안 된다. 대신 프락시는 Via 필드(14.44 절에 기술된 대로)를 포함하여야 한다. 
주의: 서버의 특정 소프트웨어 버전을 누설하는 것은 서버가 보안 허점(security holes)을 가진 것으로 알려진 소프트웨어에 대한 공격에 더욱 취약하도록 만들 수 있다. 서버 구현자는 이 필드를 설정할 수 있는 선택 사항으로 만들 것을 권고한다. 


14.40. TRANSFER-ENCODING 
Transfer-Encoding general-header 필드는 송신측과 수신측 사이에 메시지를 안전하게 전송하기 위해 어떤(적용되었다면) 유형의 변형이 메시지에 적용되었는지 표시한다. 이것은 전송 코딩(transfer coding)이 메시지의 특성이지 엔터티의 특성이 아니라는 점에서 Content-Encoding과 다르다. 
          Transfer-Encoding     = "Transfer-Encoding" ":" 1#transfer-coding 
Transfer codings은 3.6 절에 규정되어 있으면 그 예는, 
          Transfer-Encoding: chunked 
많은 이전 HTTP/1.0 애플리케이션은 Transfer- Encoding 헤더를 이해하지 못한다. 


14.41. UPGRADE 
Upgrade general-header는 클라이언트가 추가적으로 어떤 통신 규약을 지원하며 규약을 전환하는 것이 적절할 때 어떤 통신 규약을 사용하고자 하는지 명시할 수 있도록 한다. 
서버는 반드시 Upgrade 헤더 필드를 101 (Switching Protocols) 응답에 사용하여 어떤 규약이 전환되고 있는지 표시해야 한다. 
          Upgrade        = "Upgrade" ":" 1#product 
   For example, 
          Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 
Upgrade 헤더 필드는 HTTP/1.1에서 다른 호환되지 않는 규약으로 이전하는 간단한 메커니즘을 제공할 목적으로 사용된다. 클라이언트가 비록 현재 의 요구를 HTTP/1.1을 이용하여 작성하였다 하더라도 높은 주요 변경 버전 번호를 가진 HTTP의 이후 버전과 같은 다른 규약을 사용하고 싶다는 것을 광고할 수 있도록 하여 이를 성취한다. 이것은 클라이언트가 사용할 수 있다면 "좀더 낳은" 규약을 사용하고 싶어한다는 것을 표시하면서도 클라이언트가 좀더 보편적으로 지원되는 규약에서 요구를 시작할 수 있도록 하여 호환되지 않는 규약간의 어려운 이전을 용이하게 한다. ("좀더 낳은" 규약은 가능하면 요구하고 있는 method 및/또는 자원의 기본적인 성격에 따라 서버가 결정한다.) 
Upgrade 헤더 필드는 기존의 전송-계층 연결 위에서 애플리케이션-계층 규약을 전환하는 것에만 적용된다. Upgrade는 규약의 전환을 고집하는 데 사용할 수 없다. 전환의 수용 및 사용은 서버의 선택 사항이다. 규약 변경 후의 첫 작업은 Upgrade 헤더 필드를 포함하고 있는 첫 HTTP 요구에 대한 응답이어야 하지만 규약 변경 이후의 애플리케이션-계층 통신의 능력 및 기본적인 성격은 새롭게 선택된 규약에 전적으로 달려 있다. 
Upgrade 헤더 필드는 오직 가장 가까운 연결에만 적용된다. 따라서 Upgrade 핵심어는 Upgrade 헤더 필드가 HTTP/1.1 메시지에 존재할 때 Connection 헤더 필드(14.10 절) 내에서만 제공하여야 한다. 
Upgrade 헤더 필드는 다른 연결로의 규약 전환을 표시하는 데 사용할 수 없다. 이러한 목적에는 301, 302, 303 또는 305 방향 재설정 응답이 더 적절하다. 
이 규격은 3.1절의 HTTP 버전 규칙 및 이 규격의 향후 개정에서 규정한 것과 같이 하이퍼텍스트 전송 규약 집단에서 사용할 목적으로 오직 "HTTP"라는 이름의 규약만을 규정한다. 규약 이름을 위해 어떠한 토큰을 사용해도 되지만 클라이언트와 서버 모두가 해당 이름을 동일한 규약으로 연관시킬 때문에 유용할 것이다. 


14.42. USER-AGENT 
User-Agent request-header 필드는 요구를 만들어 낸 사용자 에이전트에 관한 정보를 포함하고 있다. 이것은 통계 목적, 규약 위반의 추적, 특정 사용자 에이전트 한계를 피하기 위해 응답을 고칠 목적으로 사용자 에이전트를 자동 인지하기 위함이다. 사용자 에이전트는 요구에 이 필드를 포함해야 한다. 이 필드는 사용자 에이전트의 중대한 부분을 형성하는 에이전트, 모든 하부 제품을 식별할 수 있는 복수의 제품 토큰(3.8절) 및 주석을 포함할 수 있다. 관례상 제품 토큰은 애플리케이션을 식별하는 중요도의 순서에 따라 열거되어 있다. 
          User-Agent     = "User-Agent" ":" 1*( product | comment ) 
예: 
          User-Agent: CERN-LineMode/2.15 libwww/2.17b3 


14.43. VARY 
Vary response-header 필드는 서버가 응답 엔터티를 서버가 주도하는 협상( 12장)을 이용한 이용 가능한 응답의 표시 방법에서 선택하였음을 표시하는 데 사용한다. Vary 헤더에 열거된 field-names은 request-headers의 field-names이다. Vary 필드 값은 주어진 헤더 필드 세트가 표시 방식이 변화할 수 있는 차원을 넘어선다는 것을 나타내거나, 변형의 차원이 명시되지 않아("*") 향후 요구의 어떠한 측면에서도 변형될 수 있다는 것을 나타낸다. 
          Vary = "Vary" ":" ( "*" | 1#field-name ) 
HTTP/1.1 서버는 반드시 서버가 주도하는 협상에 종속되는 모든 캐시할 수 있는 응답에 적절한 Vary 헤더 필드를 포함해야 한다. 이렇게 하면 캐시가 해당 자원에 대한 향후 요구를 적절하게 해석할 수 있도록 하며 사용자 에이전트에게 해당 자원에 대한 협상이 존재함을 알릴 수 있다. 서버는 서버가 주도하는 협상에 종속되는 캐시할 수 없는 응답에 적절한 Vary 헤더 필드를 포함해야 한다. 이것이 사용자 에이전트에게 응답이 변형될 수 있는 차원에 관한 유용한 정보를 제공할 수 있기 때문이다. 
Vary 헤더 필드 값에 의하여 명명되는 헤더 필드의 세트는 "selecting" request-headers로 알려져 있다. 
캐시가 Request-URI가 Vary 헤더를 포함한 하나 또는 그 이상의 캐시 엔트리를 명시하는 계속적인 요구를 수신했을 때 캐시된 Vary 헤더에 명명된 모든 헤더가 새로운 요구에 있거나 이전 요구의 모든 저장된 selecting request-headers가 새로운 요구의 해당 헤더와 일치하지 않는 한 캐시는 절대 이러한 캐시 엔트리를 이용하여 새로운 요구에 대한 응답을 구성해서는 안 된다. 
두 요구는 메시지 헤더에 관한 4.2 절의 규칙에 따라 동일한 필드 이름의 복수 message-header 필드를 결합하거나 또한/또는 선형 공백문자(LWS)를 상응하는 BNF가 허용하는 지점에 추가하거나 삭제하여 첫 요구의 selecting request-headers가 두 번째 요구의 selecting request-headers로 변환될 수 있을 때만 일치하는 것으로 규정된다. 
"*" 의 Vary 필드 값은 아마도 request-header 필드 내용이 아닌(예를 들어 클라이언트의 네트워크 주소) 명시되지 않은 파라미터가 응답 표시 방법의 선택에 어떤 역할을 수행하고 있음을 표시한다. 해당 자원에 대해 계속되는 요구는 원서버에 의하여 적절히 해석될 수 있기 때문에 자원의 캐시된 신선한 응답을 가지고 있을 때도 캐시는 반드시 요구를(조건적일 수 있다.) 전송해야 한다. 캐시가 사용하는 Vary 헤더에 대해서는 13.6 절을 참조한다. 
Field-names 목록으로 구성된 Vary 필드 값은 응답을 위해 선택된 표시 방식이 최적의 표시 방법을 선택할 때 열거된 request-header 필드 값만을 고려하는 선택 알고리즘에 기초하고 있다는 것을 표시한다. 캐시는 열거된 필드 이름을 위해 동일한 값으로 응답이 신선한 시간 동안만 향후의 요구에서 동일한 선택을 하게 되리라 가정해도 된다. 
주어진 field-names은 이 규격에서 규정한 표준 request-header 세트에 한정된 것은 아니다. 필드 이름은 대소문자를 구별한다. 


14.44. VIA 
게이트웨이나 프락시는 반드시 Via general-header 필드를 사용하여 요구를 만들었을 때는 사용자 에이전트와 서버 사이의, 응답을 수신했을 때는 원서버와 클라이언트 사이의 가장 가까운 규약 및 수신측을 표시해야 한다. 이것은 RFC 822의 "Received" 필드와 유사하다. 또한 이것을 메시지 전달(message forwards)을 추적하고, 요구 루프(request loops)를 피하며 request/response chain을 따라 모든 송신측의 규약 능력을 식별하는 데 사용하도록 계획되었다. 
      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] ) 
      received-protocol         = [ protocol-name "/" ] protocol-version 
      protocol-name             = token 
      protocol-version          = token 
      received-by               = ( host [ ":" port ] ) | pseudonym 
      pseudonym         = token 
Received-protocol은 request/response chain의 각 부분(segment)을 따라 서버가 클라이언트가 수신하는 메시지의 규약 버전을 표시한다. Received-protocol은 업스트림(upstream) 애플리케이션에 관한 정보를 모든 수신측이 볼 수 있도록 하기 위해 메시지가 전달되었을 때 Via 필드 값에 추가된다. 
Protocol-name 은 그것이 "HTTP"일 때만 선택 사항이다. Received-by 필드는 보통 계속적으로 메시지를 전달하는 수신측 서버나 클라이언트의 호스트나 선택적인 포트 번호이다. 그러나 진짜 호스트가 민감한 정보를 가진 것으로 간주된다면 가명(pseudonym)으로 대체할 수 있다. 포트가 주어지지 않았으면 received-protocol의 기본 포트인 것으로 가정할 수 있다. 
복수의 Via 필드 값은 메시지를 전달한 각각의 프락시나 게이트웨이를 표시한다. 각각의 수신측은 마지막 결과가 전송한 애플리케이션의 순서에 따라 순서를 정할 수 있도록 자신의 정보를 반드시 추가해야 한다. 
Via 헤더 필드에 주석을 사용하여 User-Agent나 Server 헤더 필드와 유사하게 수신측 프락시나 게이트웨이의 소프트웨어를 식별할 수 있다. 그러나 Via 필드의 모든 주석은 선택적이며 메시지를 전달하기 이전에 수신측이 삭제할 수 있다. 
예를 들어 HTTP/1.0 사용자 에이전트에서 요구 메시지를 HTTP/1.1을 이용하여 "fred"라는 코드 이름이 붙은 내부 프락시로 전달할 수 있다. 내부 프락시는 요구를 nowhere.com에 있는 공공 프락시로 전달하며 nowhere.com은 요구를 www.ics.uci.edu에 있는 원서버에 전달하여 요구 처리를 완료한다면 www.ics.uci.edu가 수신한 요구는 다음의 Via 헤더 필드를 가지게 될 것이다. 
          Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) 
네트워크 방화벽(firewall)의 입구로 사용되는 프락시나 게이트웨이는 기본적으로 방화벽 영역 내의 호스트의 이름이나 포트를 전달해서는 안 된다. 이 정보는 명백하게 활성화되었을 때만 전파할 수 있다. 활성화되지 않았으면 방화벽 뒤의 모든 호스트의 received-by host는 해당 호스트의 적절한 가명(pseudonym)으로 대체되어야 한다. 
내부 조직을 숨겨야 한다는 강한 사생활 보호 필요 조건을 가진 조직을 위해 프락시는 동일한 received-protocol 값을 가진 Via 헤더 필드 엔트리의 순서가 정해진 순차를 단일 엔트리로 결합할 수도 있다. 예를 들면, 
          Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 
을 다음과 같이 축소할 수 있다. 
          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 
애플리케이션은 복수의 엔트리를 그것들이 동일한 조직 통제 밑에 있거나 호스트가 가명으로 대체되지 않는 한 결합해서는 안 된다. 애플리케이션은 상이한 received-protocol 값을 가지고 있는 엔트리를 절대로 결합해서는 안 된다. 


14.45. WARNING 
Warning response-header 필드는 응답 상태 코드가 반영하지 않은 응답 상태에 관한 정보를 전송하는 데 사용한다. 이 정보는 비록 배타적이진 않지만 대개 캐시 작업에 발생할 수 있는 의미 투명성(semantic transparency)의 결여에 대한 경고를 하는 데 사용한다. 
Warning 헤더는 다음을 이용하여 응답과 함께 발송된다. 
          Warning       = "Warning" ":" 1#warning-value 
          warning-value         = warn-code SP warn-agent SP warn-text 
          warn-code             = 2DIGIT 
          warn-agent            = ( host [ ":" port ] ) | pseudonym 
                          ; Warning 헤더를 추가하는 서버의 이름 또는 별명 
  ; 디버깅에 사용한다. 
          warn-text             = quoted-string 
하나의 응답은 하나 이상의 Warning 헤더를 포함할 수 있다. 
Warn-text는 응답을 수신하는 인간 사용자가 가장 잘 이해할 수 있는 자연적인 언어 및 문자 집합으로 표시해야 한다. 이에 대한 결정은 캐시나 사용자의 위치, 요구의 Accept-Language 필드, 응답의 Content-Language 필드 등 사용 가능한 어떤 정보에 기초해도 된다. 기본적인 언어는 영어이며 기본 문자 집합은 ISO-8859-1이다. 
ISO-8859-1 이외의 문자 집합이 사용되었으면 RFC 1522 [14]에 기술한 method를 사용하여 warn-text 내에 인코딩해야 한다. 
어떠한 서버나 캐시도 응답에 Warning 헤더를 추가할 수 있다. 새로운 Warning 헤더는 모든 기존 Warning 헤더 다음에 추가해야 한다. 캐시는 응답과 함께 수신한 어떠한 Warning 헤더도 삭제해서는 안 된다. 그러나 캐시가 성공적으로 캐시 엔트리를 검증했으면 특정 Warning 코드가 명시한 경우를 제외하고는 해당 엔트리에 이전에 첨가된 모든 Warning 헤더는 삭제해야 한다. 그런 다음 캐시는 응답을 검증하는 동안 수신한 어떠한 Warning 헤더라도 추가할 수 있다. 달리 표현하면 Warning 헤더는 가장 최근에 관련된 응답에 추가된 헤더이다. 
응답에 복수의 Warning 헤더가 첨부되었으며 사용자 에이전트는 응답에서 나타난 순서대로 가능한 한 많은 Warning 헤더를 표시해야 한다. 모든 경고문을 표시할 수 없을 때 사용자 에이전트는 다음의 발견법(heuristics)에 따라야 한다. 
l     응답의 초기에 나타난 warnings이 나중에 나타난 것보다 우선권을 갖는다. 
l     사용자가 선호하는 문자 집합에서 발생한 warning이 다른 문자 집합의 warnings보다 우선권을 갖는다. 그러나 warn-codes 및 warn-agents는 동일하다. 
복수의 Warning 헤더를 생성하는 시스템은 이러한 사용자 에이전트의 행태를 염두에 두고 순서를 정해야 한다. 
다음은 현재 정의된 warn-codes이며 영어로 추천 warn-text 및 의미를 기술하고 있다. 

10 Response is stale 
리턴 된 응답이 낡을 때는 언제나 반드시 포함해야 한다. 캐시는 이 경고를 어떠한 응답에도 추가할 수 있지만 응답이 새로운 것으로 알려지기 전에는 절대 삭제해서는 안 된다. 
11 Revalidation failed 
서버에 도달하지 못하기 때문에 응답을 재검증하려는 시도가 실패하여 캐시가 낡은 응답을 리턴하게 되면 반드시 포함해야 한다. 캐시는 이 경고를 어떠한 응답에도 추가할 수 있지만 응답을 성공적으로 재검증하기 전에는 절대 삭제해서는 안 된다. 
12 Disconnected operation 
캐시가 의도적으로 일정기간 동안 나머지 네트워크로부터 단절되었을 때는 포함해야 한다. 
13 Heuristic expiration 
캐시가 발견법 상 신선한 기간을 24 시간 이상으로 선택하거나 응답의 경과 시간이 24시간 이상일 때는 반드시 포함해야 한다. 
14 Transformation applied 
가장 가까운 캐시나 프락시가 이 Warning 코드가 응답에 포함되어 있지 않은 한 content-coding(Content-Encoding 헤더에 명시된 것처럼) 또는 응답의 media-type (Content -Type 헤더에 명시된 것처럼)에 변형을 가하는 변경 사항을 적용했을 때 반드시 추가해야 한다. 재검증 후에도 응답에서 삭제해서는 안 된다. 
99 Miscellaneous warning 
경고 텍스트는 인간 사용자에게 제공하기 위해 또는 로깅하기 위해 자의적인 정보를 포함할 수 있다. 이 경고를 수신한 시스템은 절대로 어떠한 자동 작업도 수행해서는 안 된다. 


14.46. WWW-AUTHENTICATE 
WWW-Authenticate response-header 필드를 반드시 401(Unauthorized) 응답 메시지에 포함해야 한다. 필드 값은 Request-URI에 적용할 수 있는 인증 획득 scheme 및 파라미터를 나타내는 최소한 하나의 인증 시도(challenge)로 구성된다. 
          WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge 
11 장에 HTTP 접근 인증 획득 절차가 기술되어 있다. 사용자 에이전트는 WWW-Authenticate 필드 값을 분석할 때 하나 이상의 WWW-Authenticate 헤더 필드가 있으면 인증 시도의 내용이 인증 파라미터의 콤마로 분리된 목록을 포함하고 있기 때문에 각별한 주의를 해야 한다. 

[출처] HTTP 헤더 필드 정의|작성자 루든