참고 자료

• 이병록님이 번역하신 HTTP 1.1 Semantics and Content 번역본
  https://roka88.dev/106
• MDN Web Docs
  https://developer.mozilla.org/ko/docs/Web/HTTP

이외 자료는 내용 중 링크 추가

틀린 내용, 부족한 내용 꼭 지적 부탁드립니다!

5. Request Header Fields

클라이언트는 요청 헤더 필드를 보내 요청 컨텍스트에 대한 자세한 정보를 제공하거나,
대상 리소스 상태에 따라 요청을 조건화하거나, 응답에 대한 기본 형식을 제안하거나,
인증 정보를 제공하거나, 예상 요청 처리를 수정합니다.
이 필드는 프로그래밍 언어 메서드 호출의 매개 변수와 유사한 요청 수정자 역할을 합니다.

5.1. Controls

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

• Cache-Control
• Expect
• Host
• Max_Forwards
• Pragma
• Range
• TE

5.1.1. Expect

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

Expect = "100-continue"

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

100(continue) 이외의 417(expectation Failed) 상태 코드로 응답하여 예상하지 못한 기대치를 충족할 수 없음을 나타낼 수 있다.

100 continue 기대치는 수신자에게 클라이언트가 요청에서 (아마도 큰) 메시지 본문을 전송하기 이전에
100(continue) 임시 응답을 받기를 원함을 알린다. 이를 통해 클라이언트는 실제로 메시지 본문을 보내기 전에 메시지 본문을 보낼 수 있는지 확인 할 수 있으며, 이는 메시지 본문이 크거나 클라이언트가 오류가 발생할 것으로 예상할 때 효율성을 향상시킬 수 있습니다.
(e.g, 상태 변경 메서드를 보낼때, 처음으로, 이전에 확인된 인증 자격 없이)

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

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를 생성해서는 안된다.
• 요청 메시지를 보내기 전에 100(Continue) 응답을 기다리는 클라이언트는 100-continue가 포함된 Expect 헤더 필드를 전송해야 한다.
• 100-continue를 전송하는 클라이언트는 특정 시간 동안 기다릴 필요가 없다. 그러한 클라이언트는 아직 응답을 받지 못했더라도 메시지 본문을 전송하는 것을 계속할 수 있다.
• 또한, 100 (continue) 응답은 HTTP/1.0를 통해 전송할 수 없으므로, 해당 클라이언트는 메시지 본문을 보내기 전에 무기한으로 기다려서는 안 된다.
• 100-continue를 포함하는 요청에 응답하여 417 (Expectation Failed) 상태 코드를 수신하는 클라이언트는 응답 체인이 기대한 것과 다름을 나타낼 뿐이므로 (e.g, HTTP/1.0 서버를 경유함) 100-continue 없이 해당 요청을 반복해야 한다.

서버를 위한 요구사항으로

• HTTP/1.0 요청에서 100-continue를 수신하는 서버는 해당 기대를 무시해야 한다.
• 서버는 해당 요청에 대한 메시지 본문의 일부 또는 전부를 이미 수신했거나 프레임에 메시지 본문이 없는 것으로 표시된 경우 100(Continue) 응답 전송을 생략할 수 있다.
• 100 (Continue) 응답을 전송하는 서버는 커넥션이 조기에 종료되지 않는 한 메시지 본문이 수신되고 처리되면 최종 상태 코드를 전송해야 한다.
• 전체 메시지 본문을 읽기 전에 최종 상태 코드로 응답하는 서버는 커넥션을 종료할 것인지 또는 요청 메시지를 계속 읽고 폐기할 것인지를 해당 응답에 표시해야 한다.

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

프록시는 request-line 및 헤더 필드만 검사하여 상태를 확인할 수 있는 경우, HTTP/1.1 (또는 그 이상) request-line 및 100-continue를 포함하고 요청 메시지 본문이 따를 것임을 나타내는 전체 헤더 부문을 수신한 후 최종 상태 코드를 사용하여 응답을 즉시 전송하거나, 해당 request-line 및 헤더 부문을 다음 인바운드 서버로 전달하며 원서버를 향해 요청을 전송해야 한다. 프록시가 다음 인바운드 서버가 HTTP/1.0만 지원한다고 믿는 경우 (구성 또는 과거 상호 작용에서) 프록시는 클라이언트가 메시지 본문을 보내도록 권장하기 위해 100 (Continue) 응답을 즉시 생성할 수 있다.

참고: Expect 헤더 필드는 중간 100 (Continue) 응답을 요청하는 수단 및 반드시 이해해야 하는 확장을 표시하는 일반적인 메커니즘으로 HTTP/1.1의 최초 발행 후 추가 되었다. 그러나 확장 메커니즘은 클라이언트에 의해 사용되지 않았고, 반드시 이해되어야 하는 요구사항은 많은 서버에 의해 구현되지 않아 확장 메커니즘이 무용지물이 되었다. 이 명세는 100-continue 저의와 처리를 단순화하기 위해 확장 메커니즘을 제거하였다.

5.1.2. Max-Forwards

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

Max-Forwards = 1*DIGIT

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

Max-Forwards 헤더 필드가 포함된 TRACE 또는 OPTIONS 요청을 수신한 각 중개자는 요청을 전달하기 전에 해당 값을 확인하고 갱신해야 한다. 수신된 값이 0인 경우, 중개자는 요청을 전달하지 않아야 하며, 대신 중개자는 최종 수신자로 응답해야 한다. 수신한 Max-Forwards 값이 0보다 클 경우, 중개자는 수신한 값이 Max-Forwards에 대해 수신자의 최대 지원 값 또는 Max-Forwards 필드 값에서 1 감소된 값을 사용하여 전달된 메시지에 갱신된 Max-Forwards 필드를 생성해야한다.

수신자는 다른 요청 메서드 (OPTIONS, TRACE가 아닐때) 수신한 Max-Forwards 헤더 필드를 무시할 수 있다.

5.2 Conditionals

HTTP 조건부 요청 헤더 필드는 클라이언트가 대상 리소스의 상태에 전제 조건을 둘 수 있도록 하여 전제 조건이 거짓으로 평가하면 메서드 의미론에 해당하는 조치가 적용되지 않도록 한다. 이 명세에 의해 정의된 각 전제조건은 대상 리소스의 이전 representation에서 얻은 검증자 집합과 선택된 representation에 대한 현재 검증자 상태 간의 비교로 구성된다. 따라서 이러한 전제 조건은 대상 리소스의 상태가 클라이언트가 알고 있는 특정 상태 이후 변경되었는지 여부를 평가한다. 그러한 평가의 효과는 RFC7232의 Section 5(아직 안읽어봄)에서 정의한 조건부 메서드 의미와 선택에 따라 달라진다.

• If-Mactch
• If-None-Match
• If-Modified-Since
• If-Unmodified-Since
• If-Range

5.3 Content Negotitation

다음 요청 헤더 필드는 사용자 에이전트에 의해 응답 내용의 협상을 위해 전송된다. 이러한 필드에서 전송되는 환경설정은 대상 리소스의 representation, 오류 또는 처리 상태의 표현, 프로토콜 내에 나타날 수 있는 기타 텍스트 문자열까지 포함하여 응답의 모든 내용에 적용된다.

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language

5.3.1. Quality Values

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

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

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

아래의 예를 보면 가중치 별로 우선 순위가 정해진다.

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

• text/html and application/xhtml+xml 1.0
• application/xml 0.9
• / 0.8

두번째 예를 보면 가중치가 동일하지만 구체적으로 명시한 값이 우선순위가 높음을 알 수 있다.

text/html;q=0.8,text/*;q=0.8,*/*;q=0.8

• text/html 0.8 (but totally specified)
• text/* 0.8 (partially specified)
• / 0.8 (not specified)

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

5.3.1. Accept

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

Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
          / ( type "/" "*" )
          / ( type "/" subtype )
          ) *( OWS ";" OWS parameter ) 
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

별표 " " 문자는 모든 미디어 타입을 나타내며 " / " 는 해당 유형의 모든 하위 타입을 타나내는 " type/ "와 함께 미디어 타입을 범위로 그룹화하는 데 사용된다. 미디어 범위는 해당 범위에 적용되는 미디어 타입 매개변수를 포함할 수 있다.

각 미디어 범위에는 0개 이상의 적용 가능한 미디어 타입 매개변수(charset), 상대 가중치를 나타내는 선택적 "q" 매개변수 및 그 이상의 확장 매개변수가 뒤 따를 수 있따.
"q" 매개변수는 두 매개변수 집합 사이에 구분자 역할을 하기 때문에 확장자(accept-ext)가 있는 경우 필요하다.

참고 : "q" 매개변수 이름을 사용하여 확장 매개변수 승인에서 미디어 타입 매개변수를 구분하는 것은 과거 관행 때문이다. "q"라는 이름의 미디어 타입 매개변수가 미디어 범위에 사용될 수 없지만, IANA 미디어 타입 레지스트리에 "q"매개변수가 없고 Accept에 있는 미디어 타입 매개변수가 드물게 사용된다는 점에서 이러한 문제는 어려울 것으로 생각된다. 미래의 미디어 타입은 "q"라는 매개변수를 동록하는것을 꺼린다.

예를 들어

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

는 audio/basic를 선호하지만, 80%의 품질 저하 후 가장 적합한 오디오 타입을 보내달라 라는 의미이다.

Accept 헤더 필드가 없는 요청은 사용자 에이전트가 응답에 대한 모든 미디어 타입을 수락함을 의미한다.
요청에 헤더 필드가 있고 응답에 사용할 수 있는 representation 중 허용가능한 것으로 나열된 미디어 타입이 없는 경우, 406(Acceptable) 응답을 전송하여 헤더 필드를 존중하거나, 응답을 협상 대상이 아닌것처럼 처리하여 헤더 필드를 무시할 수 있다.

예를 들어 아래는 "text/html과 text/x-c가 동일하게 가중치를 가지는 미디어 타입이지만, 만약 그것들이 존재하지 않는다면, text/x-dvi 표현을 보내고, 만약 그것이 존재하지 않는다면, text/plain 표현을 보내라"로 해설될 것이다.

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

미디어 범위는 더 구체적인 미디어 범위 또는 특정 미디어 타입에 의해 재정의 될 수 있다. 두 개 이상의 미디어 범위가 특정 타입에 적용되는 경우 가장 구체적인 참조가 우선한다. 예를 들면 아래와 같은 우선 순위를 갖는다.

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/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

1. text/html;level=1 1.0
2. text/html 0.7
3. text/plain 0.3
4. image/jpeg 0.5
5. text/html;level=2 0.4
6. text/html;level=3 0.7

5번이 6번보다 가중치가 낮지만 높은 레벨을 가지기 때문에 높은 우선순위를 가지게 된다.

참고 : 사용자 에이전트에 특정 미디어 범위에 대한 기본 품질 값 집합이 제공될 수 있다. 단, 사용자 에이전트가 다른 렌더링 에이전트와 상호 작용할 수 없는 폐쇄형 시스템이 아닌 한, 이 기본 설정은 사용자가 구성해야 한다.

5.3.3. Accept-Charset

"Accept-Charset" 헤더 필드는 사용자 에이전트가 텍스트 응답 내용에서 허용되는 charset(이하 문자 집합)을 표시하기 위해 전송할 수 있다. 이 필드는 보다 포괄적이거나 특수 목적의 문자 집합을 이해할 수 있는 사용자 에이전트가 해당 문자 집합 정보를 나타낼 수 있는 원서버에 해당 기능을 수용할 수 있도록 한다.

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

사용자 에이전트는 5.3.1.에서 정의한 바와 같이 해당문자 집합에 대한 사용자의 상대적 선호도를 나타내기 위해 품질 값을 각 문자 집합과 연결할 수 있다.
예시로는 아래와 같을 수 있다.

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

Accept-Charset 필드에 있는 경우 특수 값 *은 Accept-Charset 필드의 다른곳에서 언급되지 않은 모든 문자 집합과 일치한다. Accept-Charset 필드에 *가 없는 경우, 필드에 명시적으로 언급되지 않은 모든 문자 집합은 클라이언트에 "not acceptable" 것으로 간주 된다.

Accept-Charset 헤더 필드가 없는 요청은 사용자 에이전트가 응답에 대한 모든 문자 집합을 수용함을 의미한다. 대부분의 범용 사용자 에이전트는 특별히 구성 되지 않은 한 Accept-Charset를 발송하지 않는데, 이는 지원되는 문자 집합의 상세 목록을 통해 서버가 사용자 에이전트의 요청 특성에 따라 개인을 쉽게 식별할 수 있기 때문이다.

요청에 Accept-Charset 헤더 필드가 있고 응답에 대해 사용 가능한 표현 중 허용 가능한 것으로 나열된 문자 집합이 없는 경우, 원서버는 406(Not Acceptable) 응답을 전송하여 헤더 필드를 존중하거나 리소스를 콘텐츠 협상의 대상이 아닌 것처럼 처리하여 헤더 필드를 무시할 수 있다.

5.3.4. Accept-Encoding

사용자 에이전트는 "Accept-Encoding" 헤더 필드를 사용하여 응답에서 허용되는 content-coding 응답을 표시할 수 있다. "identity" 토큰은 인코딩이 선호되지 않을때 통신하기 위해 "no encoding"의 동의어로 사용된다.

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

각 codings 값에는 인코딩에 대한 가중치를 나타내는 관렴 품질 값이 제공될 수 있다.
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에 대한 환결 설정이 없음을 의미한다. 이것은 서버가 응답에 어떤 content-coding도 사용할 수 있도록 허용하지만, 사용자 에이전트가 모든 인코딩을 올바르게 처리할 수 있음을 의미하지는 않는다.

서버는 다음 규칙을 사용하여 주어진 표현에 대한 content-coding이 허용되는지 여부를 테스트 한다.
1. 요청에 Accept-Encoding 필드가 없는 경우, 모든 content-coding은 사용자 에이전트에 의해 허용 가능한 것으로 간주된다.
2. representation에 content-coding이 없는 경우, "identity"에 대한 더 구체적인 항목 없이 "identity;q=0" 또는 "*;q=0"를 명시하는 Accept-Encoding 필드에 의해 특별히 제외되지 않는 한 기본적으로 허용된다.
3. representation의 content-coding이 Accept-Encoding 필드에 나열된 content-codings 중 하나인 경우, q=0을 동반하지 않는 한 허용된다.
4. 여러개의 content-codings가 허용되는 경우, 0이 아닌 q값이 가장 높은 content-coding이 선호된다.

field-value가 비어있는 Accept-Encoding 헤더 필드는 사용자 에이전트가 응답에 대한 content-coding을 원하지 않음을 의미한다.
요청에 Accept-Encoding 헤더 필드가 있고 응답에 대해 사용 가능한 representation 중 허용 가능한 것으로 나열된 content-coding이 없는 경우, 원 서버는 content-coding 없이 응답을 보내야 한다.

참고 : 대부분의 HTTP/1.0 응용 프로그램은 content-codings와 관련된 q값을 인식하거나 준수하지 않는다. 이는 q값이 작동하지 않을 수 있고 x-gzip 또는 x-compress에서 허용되지 않을 수 있음을 의미한다.

5.3.5. Accept-Language

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

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

각 language-range는 해당 범위로 지정된 언어에 대한 사용자의 선호도 추정을 나타내는 관련 품질 값을 부여할 수 있다. 예를 들면 한국어를 선호하지만 영국 영어와, 다른 종류의 영어를 받아들일것이다 라는 의미를 아래처럼 표현한다.

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

Accept-Language 헤더 필드가 없는 요청은 사용자 에이전트가 응답에 대한 모든 언어를 수용하는 것을 의미한다.
요청에 헤더 필드가 있고 응답에 사용할 수 있는 표현 중 매칭하는 언어 태그가 없는 경우, 원서버는 응답을 협상 대상이 아닌것처럼 처리하여 헤더 필드를 무시하거나 406(Not Acceptable) 응답을 보내 헤더 필드를 존중할 수 있다. 그러나, 후자는 권장되지 않는다. 그 이유는 사용자가 사용할 수 있는 콘텐츠에 접근하는 것을 막을 수 있기 때문이다.(예: 번역 소프트웨어 사용)

일부 수신자는 언어 태그가 내림차순 우선순위의 표시로 나열되는 순서를 취급하는데, 특히 동일한 품질 값이 할당된 태그의 경우(어떤 값도 q=1과 동일하지 않음)에 참고한다. 그러나 이런 행동은 믿을 수 없다. 일관성과 상호 운용성을 극대화 하기 위해, 많은 사용자 에이전트는 각 언어 태그에 고유한 품질 값을 할당하는 동시에 품질을 낮추는 순서로 나열한다.

모든 요청에서 사용자의 언어 선호도가 완전한 Accept-Language 헤더 필드를 전송하는 것은 사용자의 개인 정보 보호 기대에 반대될 수 있다.

이해할 수 있는 사항은 개별 사용자에게 매우 의존적이기 때문에, 사용자 에이전트는 (사용자 에이전트 자체의 구성을 통해 또는 사용자 제어 가능한 시스템 설정으로 기본 설정) 언어 선호에 대한 사용자 제어를 허용해야 한다. 사용자에게 이러한 제어 권한을 제공하지 않는 사용자 에이전트는 언어 허용 헤더 필드를 전송해서는 안 됩니다.

참고 : 사용자 에이전트는 사용자가 위에서 설명한 언어 매칭의 세부사항을 거의 알지 못하기 때문에 기본 설정을 설정할 때 사용자에게 지침을 제공해야 한다.
예를 들어, 사용자는 "en-gb"를 선택할 때 영국식 영어를 사용할 수 없는 경우 어떤 종류의 영어 문서도 제공된다고 가정할 수 있다. 이러한 경우 사용자 에이전트는 더 나은 일치 동작을 위해 목록에 "en"을 추가하도록 제안할 수 있다.

5.4. Authentication Credentials

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

5.5 Request Context

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

5.5.1. From

"From" 헤더 필드에는 요청된 사용자 에이전트를 제어하는 사용자의 인터넷 전자 메일 주소가 포함되어 있다.
주소는 RFC5322에서 "mailbox"에 의해 정의된 대로 기계적으로 사용할 수 있어야 한다.

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

From: [email protected]

From 헤더 필드는 로봇이 아닌 사용자 에이전트에 의해 전송되는 경우가 거의 없다. 사용자 에이전트는 사용자의 개인 정보 보호 또는 사이트의 보안 정책과 충돌할 수 있으므로 사용자의 명시적 구성 없이 From 헤더 필드를 보내서는 안 된다.

로봇틱(자동화 기계 의미인듯) 사용자 에이전트는 로봇이 과도한 요청, 원하지 않는 요청 또는 잘못된 요청을 보내는 경우와 같이 서버에서 문제가 발생할 경우 로봇을 실행할 담당자에게 연락할 수 있도록 유효한 From 헤더 필드를 전송해야 한다.

대부분의 수신자는 From 헤더 필드 값을 공용 정보로 간주하므로 서버는 접근 제어 또는 인증에 From 헤더 필드를 사용해서는 안 된다.

5.5.2. Referer

"Referer" 헤더 필드는 사용자 에이전트가 대상 URI를 얻은 리소스에 대한 URI 참조이다.
사용자 에이전트는 Referer 필드 값을 생성 할 때 URI 참조 [RFC3986]의 조각 및 사용자 정보 구성 요소를 포함하지 않아야합니다.

Referer = absolute-URI / partial-URI

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

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

대상 URI가 자체 URI가 없는 소스(예: 사용자 키보드의 입력 또는 사용자의 책갈피/즐겨찾기 내 항목)에서 가져온 경우, 사용자 에이전트는 Referer 필드를 제외하거나 "about:blank" 값으로 전송해야 합니다.

Referer 필드는 사용자의 요청 컨텍스트 또는 검색 기록에 대한 정보를 공개 할 수 있습니다.
이는 참조 리소스의 식별자가 개인 정보 (예 : 계정 이름) 또는 기밀로 간주되는 리소스 (예 : 방화벽 뒤 또는 보안 서비스 내부와 같은).
대부분의 범용 사용자 에이전트는 참조 리소스가 로컬 "파일"또는 "데이터"URI 인 경우 Referer 헤더 필드를 전송하지 않습니다.
참조 페이지가 보안 프로토콜로 수신 된 경우 사용자 에이전트는 보안되지 않은 HTTP 요청에서 Referer 헤더 필드를 보내지 않아야합니다.

일부 중개자는 나가는 요청에서 Referer 헤더 필드를 무차별 적으로 제거하는 것으로 알려져 있습니다.
이는 사용자에게 훨씬 더 해로울 수있는 CSRF 공격에 대한 보호를 방해하는 불행한 부작용이 있습니다.
Referer에서 정보 공개를 제한하려는 중개자 및 사용자 에이전트 확장은 내부 도메인 이름을 가명으로 바꾸거나 쿼리 및 / 또는 경로 구성 요소를 자르는 등의 특정 편집에 대한 변경을 제한해야합니다.
중개자는 필드 값이 요청 대상과 동일한 체계 및 호스트를 공유 할 때 Referer 헤더 필드를 수정하거나 삭제하면 안됩니다.

간단하게 Referer 요청 헤더는 현재 요청된 페이지 링크 이전의 웹 페이지 주소를 포함한다. Referer 헤더는 사람들이 어디로부터 와서 방문 중인지를 인식할 수 있도록 해주며
해당 데이터는 분석, 로깅, 캐싱 최적화에 사용될 수도 있다.

5.5.3. User-Agent

User-Agent 헤더 필드에는 요청을 시작하는 User-Agent에 대한 정보가 포함되어 있으며, 이 정보는 서버에서 보고된 상호 운용성 문제의 범위를 식별하고,
특정 사용자 에이전트 제한을 방지하고, 브라우저 또는 운영 체제 사용과 관련된 분석을 위해 응답을 조정하기 위해 자주 사용 된다.
특별히 구성되지 않은 경우 사용자 에이전트는 각 요청에서 User-Agent 필드를 전송 해야 한다.

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

User-Agent 필드 값은 하나 이상의 product 식별자로 구성되며, 각각 0개 이상의 주석으로 구성되며, 사용자 에이전트 소프트웨어와
그 중요한 하위 제품을 함께 식별한다. 관용적으로 product 식별자는 사용자 에이전트 소프트웨어 식별에 대한 중요도의 감소 순서에 따라 나열된다.
각 product 식별자는 이름과 선택 버전으로 구성 된다.

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

발신자는 생성된 product 식별자를 product 식별에 필요한 것으로 제한해야 하며, 발신자는 product 식별자 내에서 광고나 기타 비필수 정보를 생성해서는 안 된다.
발신자는 버전 식별자가 아닌 product-version에서 정보를 생성해서는 안 된다.(즉, 동일한 제품 이름의 연속 버전은 product 식별자의 product-version 부분에서만 달라야 한다.)

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_1)
            AppleWebKit/537.36 (KHTML, like Gecko)
            Chrome/88.0.4324.182 
            Safari/537.36

사용자 에이전트는 불필요한 세부 정보가 포함된 User-Agent 필드를 생성해서는 안되며, 제 3자의 하위 제품 추가를 제한해야 한다.
지나치게 길고 상세한 User-Agent 필드 값은 요청 대기 시간을 증가시키고 사용자가 자신의 뜻에 반하여 식별될 위험("fingerprinting")을 증가 시킨다.

마찬가지로, 구현은 필드의 목적을 회피하기 떄문에 다른 구현의 product 토큰을 사용하여 호환성을 선언하지 않도록 권장된다. 사용자 에이전트가 다른 사용자 에이전트로 위장하는 경우, 수신자는 사용 중인 실제 사용자 에이전트에 대해 제대로 작동하지 않더라도 사용자가 의도적으로 식별된 사용자 에이전트에 적합한 응답을 보기를 원한다고 가정할 수 있다.

결국엔 내가 어떤 기기를 사용하는지를 알려주고 대부분은 통계 자료로 사용된다고 한다.