7. Response Header Fields
Last updated
Last updated
응답 헤더 필드는 서버가 status-line에 배치된 정보를 넘어 응답에 대한 추가 정보를 전달할 수 있도록 한다. 이러한 헤더 필드는 서버에 대한 정보, 대상 리소스에 대한 추가 액세스 또는 관련 리소스에 대한 정보를 제공한다.
응답 헤더 필드는 상태 코드를 보충하거나 캐시를 지시하거나 클라이언트에 다음에 어디로 가야 하는지 지시하는 제어 데이터를 제공할 수 있다.
1995년 이전에는 서버가 타임스탬프를 통신하기 위해 일반적으로 사용하는 세 가지 다른 형식이 있었다. 기존 구현과의 호환성을 위해 세 가지 모두 여기에 정의되어 있다. 선호되는 형식은 인터넷 메시지 형식[RFC5322]에서 사용하는 날짜 및 시간 규격의 fixed-length 및 single-zone 부분 집합이다.
HTTP-date = IMF-fixdate / obs-date
선호하는 형식의 예는
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
사용되지 않는 두 형식의 예는 다음과 같다.
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
HTTP 헤더 필드에서 타임스탬프 값을 구문 분석하는 수신자는 세 가지 HTTP-date 형식을 모 두 수용해야 한다.(MUST)
발신자가 HTTP-date로 정의된 하나 이상의 타임스탬프를 포함하는 헤더 필드를 생성할 때, 발신자는 반드시 IMF-fixdate 형식으로 타임스탬프를 생성해야 한다.(MUST)
HTTP-date 값은 UTC(Coordinated Universal Time)의 인스턴스로서의 시간을 나타낸다.
HTTP-date는 대소문자를 구분한다. 발신자는 문법에 SP로 구체적으로 포함된 공간을 초과하여 HTTP-date에 추가 공백을 생성해서는 안 된다.(MUST NOT)
두 자릿수를 사용하는 rfc850-date 형식의 타임스탬프 값을 받는 사람은 앞으로 50년 이상 것으로 보이는 타임스탬프를 마지막 two-digit가 같았던 과거의 가장 최근 연도를 나타내는 것으로 해석해야 한다.(MUST)
참고: date/time 스탬프 형식에 대한 HTTP 요구 사항은 프로토콜 스트림 내의 사용에만 적용된다. 사용자 프레젠테이션, 요청 기록 등에 이러한 형식을 사용할 필요는 없다.
“Date” 헤더 필드는 [RFC5322]의 Section 3.6.1에서 정의한 Origination Date Field(orig-date)와 동일한 의미를 가지며 메시지가 발생한 날짜와 시간을 나타낸다. 필드 값은 Section 7.1.1.1에서 정의한 HTTP-date다.
Date = HTTP-date
예를들어,
Date: Tue, 15 Nov 1994 08:12:31 GMT
원서버는 Coordinated Universal Time(UTC)에서 현재 인스턴스의 합당한 근사치를 제공할 수 있는 시계가 없는 경우 Date 헤더 필드를 보내서는 안 된다.(MUST NOT)
응답이 상태 코드의 1xx (Informational) 또는 5xx (Server Error) 등급인 경우 원서버는 Date 헤더 필드를 보낼수 있다.(MAY)
원서버는 다른 모든 경우 Date 헤더 필드를 전송해야 한다.(MUST)
Date 헤더 필드 없이 시계와 응답 메시지를 수신하는 수신자는 수신된 시간을 기록하고 해당 Date 헤더 필드가 캐시되거나 다운스트림에서 전달되는 경우 메시지의 헤더 부문에 해당 Date 헤더 필드를 추가해야 한다.(MUST)
“Location” 헤더 필드는 응답과 관련된 특정 리소스를 참조하기 위해 일부 응답에 사용된다. 관계의 유형은 요청 메서드와 상태 코드 의미론의 조합에 의해 정의된다.
201 (Created) 응답의 경우, Location 값은 요청에 의해 생성된 기본 리소스를 말한다. 3xx (Redirection) 응답의 경우, Location 값은 요청을 자동으로 리디렉션하기 위한 기본 대상 리소스를 가리킨다.
서버는 “Retry-After” 헤더 필드를 보내 사용자 에이전트가 후속 요청을 하기 전에 얼마나 기다려야 하는지 표시한다. 503 (Service Unavailable) 응답과 함께 전송된 경우 Retry-After 에는 클라이언트가 서비스를 사용할 수 없을 것으로 예상되는 기간이 표시된다.
두가지 사용 예시로
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120
응답의 “Vary” 헤더 필드는 메서드, Host 헤더 필드 및 요청 대상을 제외하고 요청 메시지의 어떤 부분이 이 응답을 선택하고 나타내는 원서버의 프로세스에 영향을 미칠 수 있는지 설명한다.
프락시는 “*” 값을 가진 Vary 필드를 생성해서는 안 된다.(MUST NOT)
예시로
Vary: accept-encoding, accept-language
원서버가 이 응답에 대한 내용을 선택하면서 요청의 Accept-Encoding 및 Accept-Language 필드(또는 해당 필드 없음)를 결정 요인으로 사용했을 수 있음을 나타낸다.
원서버는 두 가지 목적을 위해 필드 목록과 함께 Vary를 보낼 수 있다.
1. 캐시 수신자에게, 이후의 요청이 원래 요청과 동일한 값을 가지지 않는 한, 이후의 요청을 만족시키기 위해 이 응답을 사용해서는 안된다는 것(MUST NOT)을 통지한다 ([RFC7234]의 Section 4.1). 즉, Vary는 저장된 캐시 항목으로 새 요청을 일치시키는데 필요한 캐시 키를 확장한다.
2. 사용자 에이전트 수신자에게 이 응답은 콘텐츠 협상(Section 5.3)의 대상이며, 나열된 헤더 필드에 추가 파라미터가 제공될 경우 후속 요청으로 다른 표현이 전송될 수 있음을 통지한다.
검증자 헤더 필드는 선택된 표현에 대한 메타데이터를 전송한다(Section 3).
예를 들어 201 (Created) 응답의 ETag 헤더 필드는 새로 생성된 리소스의 표현에 대한 entity-tag를 전달하여, 이후 조건부 요청에 사용되어 “lost update” 문제를 방지할 수 있다 [RFC7232].
인증 문제는 클라이언트가 향후 요청 시 인증 자격 증명을 제공할 수 있는 메커니즘을 나타낸다.
나머지 응답 헤더 필드는 이후 요청에 사용할 수 있는 대상 리소스에 대한 자세한 정보를 제공한다.
“Allow” 헤더 필드에는 대상 리소스가 지원하는 것으로 알려진 메서드 집합이 나열된다. 이 필드의 목적은 수신자에게 리소스와 관련된 유효한 요청 메서드를 알리는 것이다.
원서버는 405 (Method Not Allow) 응답에서 Allow 필드를 생성해야 한다.(MUST)
프락시는 Allow 헤더 필드를 수정해서는 안 된.(MUST NOT)
“Server” 헤더 필드에는 요청을 처리하기 위해 원서버가 사용하는 소프트웨어에 대한 정보가 들어 있는데, 이 소프트웨어는 보고된 상호운용성 문제의 범위를 식별하는 데 도움을 주고, 특정 서버 제한을 피하기 위해 작업하거나 요청을 맞춤화하며, 서버 또는 운영체제 사용과 관련 된 분석을 위해 클라이언트가 종종 사용한다.
예시
Server: CERN/3.0 libwww/2.17
