5. Request Header Fields

클라이언트는 요청 헤더 필드를 보내 요청 컨텍스트에 대한 추가 정보를 제공하고, 대상 리소스 상태에 따라 요청을 조건부로 만들며, 응답에 대한 기본 형식을 제안하거나, 인증 자격 증 명을 제공하거나, 예상 요청 처리를 수정한다.

5.1 Controls

Controls은 요청의 특정 처리를 지시하는 요청 헤더 필드다.

5.1.1 Expect

요청의 “Expect” 헤더 필드는 요청을 적절하게 처리하기 위해 서버가 지원해야 하는 특정 동작(기대치)을 나타낸다. 이 명세에 의해 정의된 유일한 기대치는 100-continue이다.

Expect = "100-continue"

Expect field-value는 대소문자를 구분하지 않는다.

• 100-continue 이외의 Expect field-value를 수신하는 서버는 417 (Expectation Failed) 상태 코드로 응답하여 예상하지 못한 기대치를 충족할 수 없음을 나타낼 수 있다.(MAY)

100-continue는 클라이언트가 이 요청에서 (상당히 큰) 메시지 본문을 보내려고 한다는 것을 수신자에게 알려주고, 요청 라인 및 헤더 필드가 즉각적인 성공, 리다이렉트 또는 오류 응답을 야기하기에 충분하지 않을 경우 100 (Continue) 중간 응답을 받기를 희망한다.

예를들어, 다음으로 시작하는 요청에서

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

클라이언트가 불필요한 데이터 전송으로 파이프를 채우기 시작하기 전에 원서버가 401 (Unauthorized) 또는 405 (Method Not Allowed)와 같은 오류 메시지로 즉시 응답할 수 있도록 허용한다.

• 클라이언트는 메시지 본문을 포함하지 않는 요청에서 100-continue 를 생성해서는 안된다.(MUST NOT)

• 100 (Continue) 응답은 HTTP/1.0 중개자를 통해 전송할 수 없으므로, 해당 클라이언트는 메시지 본문을 보내기 전에 무기한으로 기다려서는 안 된다.(SHOULD NOT)

• HTTP/1.0 요청에서 100-continue를 수신하는 서버는 해당 기대치를 무시해야 한다.(MUST)

• 100 (Continue) 응답을 전송하는 서버는 커넥션이 조기에 종료되지 않는 한 메시지 본문이 수신되고 처리되면 최종 상태 코드를 전송해야 한다.(MUST)

• 원서버는 request-line 및 헤더 필드만 검사하여 상태를 확인할 수 있는 경우, HTTP/1.1(또는 그 이상) request-line 및 100-continue를 포함하고 요청 메시지 본문이 따를 것임을 나타내 는 전체 헤더 부문을 수신한 후 최종 상태 코드를 사용하여 응답을 즉시 전송하거나, 클라이언트가 요청의 메시지 본문을 보내도록 장려하기 위해 100 (Continue) 응답을 즉시 전송해야 한다.(MUST)

• 원서버는 100(Continue) 응답을 보내기 전에 메시지 본문을 기다려서는 안 된

  다.(MUST NOT)

5.1.2 Max-Forwards

“Max-Forwards” 헤더 필드는 요청이 프록시에 의해 전달되는 횟수를 제한하는 TRACE (Section 4.3.8) 및 OPTION (Section 4.3.7) 요청 메서드와 메커니즘을 제공한다. 이는 클라이언트가 실패한 것으로 보이거나 중간 체인의 루프로 보이는 요청을 추적하려고 할 때 유용할 수 있다.

Max-Forwards = 1*DIGIT

Max-Forwards 값은 이 요청 메시지를 전달할 수 있는 남은 횟수를 나타내는 십진수 정수다.

• Max-Forwards 헤더 필드가 포함된 TRACE 또는 OPTIONS 요청을 수신한 각 중개자는 요청을 전달하기 전에 해당 값을 확인하고 갱신해야 한다.(MUST)

• 수신된 값이 0인 경우, 중개자는 요청을 전달하지 않아야 하며,(MUST NOT)

• 대신 중개자는 최종 수신자로 응답해야 한다.(MUST)

• 수신한 Max-Forwards 값이 0보다 클 경우, 중개자는 수신한 값이 Max-Forwards에 대해 수신 자의 최대 지원 값 또는 1 감소하거 필드 값보다 작은 필드 값을 사용하여 전달된 메시지에서 갱신된 Max-Forwards 필드를 생성해야 한다.(MUST)

5.2 Conditionals

5.3 Content Negotiation

5.3.1 Quality Values

사전 협상을 위한 많은 요청 헤더 필드는 “q” (대소문자를 구분하지 않음)라는 공통 매개변수를 사용하여 관련 콘텐츠의 선호도에 상대적인 “weight”를 할당한다. 이 가중치를 “quality value"(또는 “qvalue”)이라고 하는데, 같은 매개변수 이름이 리소스를 위해 선택할 수 있는 다 양한 표현의 상대적 품질에 가중치를 할당하기 위해 서버 구성 내에서 자주 사용되기 때문이다.

가중치는 0 에서 1 사이의 범위에서 실제 숫자로 정규화되며, 여기서 0.001은 가장 선호되지 않고 1은 가장 선호되며, 0의 값은 “not acceptable”을 의미한다. “q” 매개변수가 없는 경우 기본 가중치는 1이다.

• q값을 보낸 사람은 소수점 이후 세 자리 이상의 숫자를 생성해서는 안 된다.(MUST NOT)

5.3.2 Accept

“Accept” 헤더 필드는 사용자 에이전트에서 허용 가능한 응답 미디어 타입을 지정하는 데 사용할 수 있다. Accept 헤더 필드는 인라인 이미지 요청의 경우처럼 요청이 특별히 원하는 타입의 작은 집합으로 제한되었음을 나타내는 데 사용할 수 있다.

5.3.3 Accept-Charset

“Accept-Charset” 헤더 필드는 사용자 에이전트가 텍스트 응답 내용에서 허용되는 charset(이하 문자 집합)을 표시하기 위해 전송할 수 있다.

5.3.4 Accept-Encoding

사용자 에이전트는 “Accept-Encoding” 헤더 필드를 사용하여 응답에서 허용되는 content-coding 응답(Section 3.1.2.1)를 표시할 수 있다. 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

5.3.5 Accept-Language

사용자 에이전트는 “Accept-Language” 헤더 필드를 사용하여 응답에서 선호하는 자연어 집합을 나타낼 수 있다.

• 사용자에게 이러한 제어를 제공하지 않는 사용자 에이전트는 Accept-Language 헤더 필드를 보내서는 안 된다.(MUST NOT)

5.4 Authentication Credentials

[RFC7235]에서 정의한 인증 자격 증명을 전달하는 데 두 개의 헤더 필드가 사용된다. 사용자 인증을 위한 다양한 사용자 정의 메커니즘은 [RFC6265]에서 정의한 Cookie 헤더 필드를 이러한 목적으로 사용한다는 점에 참고한다.

5.5 Request Context

다음 요청 헤더 필드는 요청 뒤에 있는 사용자, 사용자 에이전트 및 리소스에 대한 정보를 포함하여 요청 컨텍스트에 대한 추가 정보를 제공한다.

5.5.1 From

“From” 헤더 필드에는 요청된 사용자 에이전트를 제어하는 사용자의 인터넷 전자 메일 주소가 포함되어 있다.

From: [e-mail]

5.5.2 Referer

5.5.3 User-Agent

“User-Agent” 헤더 필드에는 보고된 상호운용성 문제의 범위를 식별하고, 특정 사용자 에이전트 제한을 피하기 위한 응답을 조정하거나 피하기 위해 서버가 자주 사용하는 요청의 발생 사용자 에이전트에 대한 정보가 포함되어 있으며 브라우저 또는 운영 체제사용에 대한 분석을 위해 사용된다.

• 사용자 에이전트는 특별히 구성되지 않은 한 각 요청에서 User-Agent 필드를 전송해야 한다.(SHOULD)

• 발신자는 생성된 product 식별자를 product 식별에 필요한 것으로 제한해야 하며, 발신자는 product 식별자 내에서 광고나 기타 비필수 정보를 생성해서는 안된다.(MUST NOT)

User-Agent Client Hints의 도입, UA 프리징을 대비하라