recursal/MDN huggingface dataset:
Content-Type
============

**`Content-Type`** 개체 헤더는 리소스의 media type을 나타내기 위해 사용됩니다.

응답 내에 있는 `Content-Type` 헤더는 클라이언트에게 반환된 컨텐츠의 컨텐츠 유형이 실제로 무엇인지를 알려줍니다. 브라우저들은 어떤 경우에는 MIME 스니핑을 해서 이 헤더의 값을 꼭 따르지는 않을 겁니다; 이를 막기 위해, `X-Content-Type-Options` (en-US) 헤더를 `nosniff`으로 설정할 수 있습니다.

요청 내에서, (`POST` 혹은 `PUT`처럼), 클라이언트는 서버에게 어떤 유형의 데이터가 실제로 전송됐는지를 알려줍니다.

|  |  |
| --- | --- |
| 헤더 유형 | Entity header |
| Forbidden header name | no |

문법
--
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

디렉티브
----

`media-type`

리소스 혹은 데이터의 MIME type.

charset

문자 인코딩 표준.

boundary

멀티파트 개체에 대해 `boundary` 디렉티브는 필수인데, 이메일 게이트를 통해 매우 탄탄해졌다고 알려진 캐릭터셋의 1~70개의 문자들로 구성되며, 빈 공백으로 끝나지 않습니다. 이는 메시지의 멀티 파트 경계선을 캡슐화하기 위해 사용됩니다.

예제
--

### `Content-Type` in HTML forms

HTML 폼 전송으로 일어나는 `POST` 요청 내에서, 요청의 `Content-Type`은 `<form>` 요소 상의 `enctype` 속성에 의해 지정됩니다.


```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```


요청은 다음과 같을 겁니다(여기서 설명할 필요가 없는 헤더들은 생략되었습니다):
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"
---------------------------974767299852498929531610575

some text

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)

---------------------------974767299852498929531610575--
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `Accept`과 `Accept-Charset`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`
Expires
=======

**`Expires`** 헤더는 응답이 더 이상 신선하지 않다고 판단할 날짜/시간을 포함합니다.

0과 같은, 유효하지 않은 날짜는 과거의 시간을 나타내어 리소스가 이미 만료되었음을 의미합니다.

응답 내에 "max-age" 혹은 "s-max-age" 디렉티브를 지닌 `Cache-Control` 헤더가 존재할 경우, `Expires` 헤더는 무시됩니다.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |
| CORS-safelisted response-header | yes |

문법
--
```

Expires: <http-date>
```

디렉티브
----

<http-date>

HTTP-date timestamp.

예제
--
```

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

명세
--

| Specification |
| --- |
| HTTP Caching # field.expires |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `Cache-Control`
* `Age`
Accept-Ranges
=============

**`Accept-Ranges`** 응답 HTTP 헤더는 부분 요청의 지원을 알리기 위해 서버에 의해 사용되는 표식입니다. 이 필드의 값은 범위를 정의하기 위해 사용될 수 있는 단위를 가리킵니다.

`Accept-Ranges` 헤더가 존재하면, 브라우저는 처음부터 다시 다운로드를 시작하지 않고, 중단된 다운로드를 *재개*하려고 할 것입니다.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

문법
--
```

Accept-Ranges: bytes
Accept-Ranges: none
```

디렉티브
----

`none`

지원되는 범위의 단위가 없음을 나타내는데, 이는 헤더가 존재하지 않는 경우와 동일하므로 거의 사용되지 않습니다. 그렇지만 IE9같은 브라우저의 경우 다운로드 매니저의 일시중지 버튼을 비활성화(disable) 혹은 제거(remove)할 때 쓰이곤 합니다.

`bytes`

범위는 바이트로 표현될 수 있습니다.

예제
--
```

Accept-Ranges: bytes
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.accept-ranges |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `If-Range`
* `Ranges` (en-US)
X-Forwarded-For
===============

**`X-Forwarded-For`** (XFF) 헤더는 HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 원 IP 주소를 식별하는 사실상의 표준 헤더다. 클라이언트와 서버 중간에서 트래픽이 프록시나 로드 밸런서를 거치면, 서버 접근 로그에는 프록시나 로드 밸런서의 IP 주소만을 담고 있다. 클라이언트의 원 IP 주소를 보기위해 X-Forwarded-For 요청 헤더가 사용된다.

이 헤더는 디버깅, 통계, 그리고 위치 종속적인 컨텐츠를 위해 사용되고, 클라이언트의 IP 주소 등과 같은 민감한 개인정보를 노출시킨다. 그러므로 이 헤더를 사용할 때에는 사용자의 프라이버시를 주의해야 한다.

이 헤더의 표준화된 버전은 HTTP `Forwarded` 헤더다.

`X-Forwarded-For` 은 이메일 메시지가 다른 계정으로부터 포워딩되었음을 나타내는 이메일 헤더이기도 하다.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

문법
--
```

X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

지시자
---

<client>

클라이언트 IP 주소

<proxy1>, <proxy2>

하나의 요청이 여러 프록시들을 거치면, 각 프록시의 IP 주소들이 차례로 열거된다. 즉, 가장 오른쪽 IP 주소는 가장 마지막에 거친 프록시의 IP 주소이고, 가장 왼쪽의 IP 주소는 최초 클라이언트의 IP 주소다.

예제
--
```

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
```


다른 비표준 형태:
```

# 몇몇 구글 서비스에서 사용된다
X-ProxyUser-Ip: 203.0.113.19
```

기술명세
----

현재 어떠한 표준 명세에도 속하지 않는다. 이 헤더의 표준화 버전은 `Forwarded` 이다.

함께 참고할 내용
---------

* `Forwarded`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via`
Accept-Language
===============

**`Accept-Language`** 요청 HTTP 헤더는 어떤 언어를 클라이언트가 이해할 수 있는지, 그리고 지역 설정 중 어떤 것이 더 선호되는지를 알려줍니다. (여기서 언어란 프로그래밍 언어가 아니라 영어같은 자연 언어를 의미합니다.) 컨텐츠 협상을 사용하여, 서버는 제안 중 하나를 선택한 뒤, 그것을 사용하고 `Content-Language` 응답 헤더와 함께 선택된 내용을 클라이언트에게 알려줍니다. 브라우저는 사용자 인터페이스 언어에 따라 해당 헤더에 적절한 값을 설정하며 사용자가 사용자 인터페이스 언어를 변경한 경우조차도, 헤더의 값이 변경되는 일은 거의 없습니다(그리고 그런 일이 일어나게 되면 흔적이 남으므로 눈살을 찌프리게 됩니다).

이 헤더는 서버가 언어를 결정할 다른 방도(명시적인 사용자 결정에 의한 구체적인 URL과 같은)를 찾지 못한 경우 사용되는 힌트입니다. 서버는 명시적인 결정을 결코 재정의해서는 안됩니다. `Accept-Language`의 내용은 대게 사용자에 의해 좌지우지되지 못합니다(다른 나라의 인터넷 카페를 방문하여 사용하는 경우처럼); 사용자는 그들의 사용자 인터페이스의 로케일과는 다른 언어로 된 페이지에 방문하고 싶어 할 수도 있습니다.

서버가 일치되는 어떤 언어로 서브할 수 없는 경우, 이론적으로 `406` (Not Acceptable) 오류 코드를 회신하게 됩니다. 그러나, 좀 더 나은 사용자 경험을 위해, 이런 경우는 드물며 그런 경우에 가장 흔한 방법은 `Accept-Language` 헤더를 무시하는 것입니다.

|  |  |
| --- | --- |
| 헤더 유형 | Request header |
| Forbidden header name | no |
| CORS-safelisted request-header | yes |

문법
--
```

Accept-Language: <language>
Accept-Language: <locale>
Accept-Language: *

// Multiple types, weighted with the quality value syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

디렉티브
----

`<language>`

2개 혹은 3개 문자로 이루어진 문자열로 표현되는 언어

`<locale>`

전체적인 언어 태그. language 그 자체에 추가로, `'-'`뒤에 추가적인 내용을 담을 수도 있습니다. 가장 일반적인 추가 정보는 ('en-US'와 같은) 국가 변수값(variant) 혹은 사용을 위한 (`'sr-Lat'`와 같은) 알파벳 유형이 있습니다. 철자법 타입과 같은 다른 변형들(`'de-DE-1996'`)은 보통 이 헤더의 맥락에서는 사용되지 않습니다. Other variants like the type of orthography (`'de-DE-1996'`)

`*`

어떤 언어든지 상관없음; 와일드카드처럼 사용되는 `'*'`.

`;q=` (q-인자 가중치)

*weight*라고 불리는 상대적 품질 값을 사용해 표현되는 선호도에 따라 대체되는 값.

예제
--
```

Accept-Language: de

Accept-Language: de-CH

Accept-Language: en-US,en;q=0.5
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.accept-language |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* HTTP 컨텐츠 협상
* 컨텐츠 협상의 결과로 나오는 헤더: `Content-Language`
* 다른 유사한 헤더들: `TE` (en-US), `Accept-Encoding`, `Accept-Charset`, `Accept`
Via
===

**`Via`** 일반 헤더는 포워드 프록시와 리버스 프록시에 의해서 추가됩니다. 그리고 요청 또는 응답 헤더에 표시될 수 있습니다. 메시지 전달을 추적하고 요청 루프를 방지하며 요청/응답 체인에서 발신자의 프로토콜 기능을 식별하는 데 사용됩니다.

|  |  |
| --- | --- |
| Header type | 요청 헤더,
 응답 헤더 |
| 금지된 헤더 이름 | 예 |

구문
--


```http
Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
```

지시자
---

<protocol-name>

선택사항. "HTTP" 와 같은 사용된 프로토콜의 이름.

<protocol-version>

"1.1" 과 같이 사용된 프로토콜의 버전.

<host> and <port>

공용 프록시의 URL과 포트.

<pseudonym>

내부 프록시의 이름 또는 별칭.

예제
--


```http
Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # field.via |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `X-Forwarded-For`
* Heroku's proxy library Vegur
Host
====

**`Host`** 요청 헤더는 (가상 호스팅을 위해) 서버의 도메인명과 서버가 리스닝하는 (부가적인) TCP 포트를 특정합니다.

포트가 주어지지 않으면, 요청된 서버의 기본 포트(예를 들어, HTTP URL은 "80")를 의미합니다.

`Host` 헤더의 필드는 모든 HTTP/1.1 요청 메시지 내에 포함되어 전송되어야 합니다. `Host` 헤더 필드가 없거나 한 개 이상의 필드를 포함하는 HTTP/1.1 요청 메시지에 대해서는 `400` (Bad Request) 상태 코드가 전송될 것입니다.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

문법
--
```

Host: <host>:<port>
```

디렉티브
----

<host>

(가상 호스팅에 대한) 서버의 도메인 이름.

<port> Optional

서버가 리스닝하는 TCP 포트 번호.

예제
--
```

Host: developer.mozilla.org
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.host |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `400`
Access-Control-Expose-Headers
=============================

**`Access-Control-Expose-Headers`** 헤더를 통해 서버는 교차-출처 요청 (cross-origin request)에 대한 응답으로 브라우저에서 실행 중인 스크립트가 사용할 수 있는 응답 헤더를 지정할 수 있습니다.

기본적으로 CORS 안전 목록 응답 헤더만 노출됩니다. 클라이언트가 다른 헤더에 접근할 수 있도록 하려면 서버는 `Access-Control-Expose-Headers` 헤더를 사용하여 헤더를 나열해야 합니다.

|  |  |
| --- | --- |
| 헤더 타입 | 응답 헤더 |
| 금지된 헤더 이름 | no |

문법
--


```http
Access-Control-Expose-Headers: [<header-name>[, <header-name>]\*]
Access-Control-Expose-Headers: \*
```

지침
--

`<header-name>`

클라이언트가 응답에서 접근할 수 있는 헤더 이름 목록이며, 0개 이상의 콤마로 구분됩니다. CORS 안전 목록 응답 헤더에 추가 됩니다.

`*` (와일드카드)

`*`는 자격 증명이 없는 요청 (HTTP 쿠키나 HTTP 인증 정보가 없는 요청)에 대한 특별한 와일드카드 값으로 취급됩니다. 자격 증명이 있는 요청에서는 특별한 의미 없이 문자 그대로 헤더 이름 `*`로 취급됩니다.

예제
--

CORS 안전 목록 응답 헤더는 다음과 같습니다. `Cache-Control`, `Content-Language`, `Content-Length`, `Content-Type`, `Expires`, `Last-Modified`, `Pragma`.

CORS 안전 목록 응답 헤더에 없는 응답 헤더를 노출하려면 다음과 같이 지정할 수 있습니다.


```http
Access-Control-Expose-Headers: Content-Encoding
```


`Kuma-Revision`과 같은 사용자 지정 헤더를 추가로 표시하려면 여러 헤더를 콤마로 구분하여 지정할 수 있습니다.


```http
Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision
```


자격 증명이 없는 요청의 경우 서버는 와일드카드 값을 사용하여 응답하기도 합니다.


```http
Access-Control-Expose-Headers: \*
```


하지만, `Authorization` 헤더는 와일드카드로 지정할 수 없기 때문에 명시적으로 지정해야 합니다.


```http
Access-Control-Expose-Headers: \*, Authorization
```

명세
--

| Specification |
| --- |
| Fetch Standard # http-access-control-expose-headers |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`
Alt-Svc
=======

`Alt-Svc` HTTP 헤더를 사용하면 서버가 향후 요청 시 다른 네트워크 위치("대체 서비스")를 해당 오리진에 대한 권한이 있는 것으로 취급할 수 있음을 표시할 수 있습니다.

이렇게 하면 진행중인 요청에 영향을 주지 않으면서 새로운 프로토콜 버전을 알릴 수 있으며, 서버가 트래픽을 관리하는 데 도움이 될 수 있습니다. 대체 서비스를 사용하는 것은 최종 사용자에게 표시되지 않으며 URL이나 요청의 출처가 변경되지 않고 추가 왕복이 발생하지 않습니다.

구문
--


```http
Alt-Svc: clear
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>
Alt-Svc: <protocol-id>=<alt-authority>; ma=<max-age>; persist=1
```


`clear`

특수 값 `clear`는 출발지에서 해당 출발지에 대한 모든 대체 서비스를 무효화하도록 요청함을 나타냅니다.

`<protocol-id>`

ALPN 프로토콜 식별자입니다. HTTP/2의 경우 `h2`, HTTP/3 프로토콜 초안 25의 경우 `h3-25`가 그 예입니다.

`<alt-authority>`

선택적 호스트 재정의, 콜론 및 필수 포트 번호로 구성된 대체 권한을 지정하는 따옴표로 묶인 문자열입니다.

`ma=<max-age>` Optional

대체 서비스가 새로 고침된 것으로 간주되는 시간(초)입니다. 생략하면 기본값은 24시간입니다. 대체 서비스 항목은 응답의 나이(`Age` 헤더에서)를 뺀 최대 *<max-age>* 초 동안 캐시될 수 있습니다. 캐시된 항목이 만료되면 클라이언트는 더 이상 새 연결에 이 대체 서비스를 사용할 수 없습니다.

`persist=1` Optional

일반적으로 캐시된 대체 서비스 항목은 네트워크 구성이 변경되면 지워집니다. `persist=1` 매개 변수를 사용하면 이러한 변경으로 인해 항목이 삭제되지 않도록 요청합니다.

쉼표를 구분 기호로 사용하여 단일 `Alt-Svc` 헤더에 여러 항목을 지정할 수 있습니다. 이 경우 앞쪽 항목이 더 선호되는 것으로 간주됩니다.

예제
--


```http
Alt-Svc: h2=":443"; ma=2592000;
Alt-Svc: h2=":443"; ma=2592000; persist=1
Alt-Svc: h2="alt.example.com:443", h2=":443"
Alt-Svc: h3-25=":443"; ma=3600, h2=":443"; ma=3600
```

명세서
---

| Specification |
| --- |
| HTTP Alternative Services # alt-svc |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* 대체 서비스 (HTTP Working 그룹 의장인 Mark Nottingham의 `Alt-Svc`에 관한 글)
Server
======

**`Server`** 헤더는 요청을 처리하기 위한 원(origin, 原) 서버의 소프트웨어 정보를 포함하고 있습니다.

너무 길고 상세한 서버의 정보는 잠재적으로 내부 구현과 상세 정보를 이용하여 잠재적으로 공격을 받을 수 있기 때문에 피해야 합니다. 공격자들은 (약간) 쉽게 알려진 보안상의 문제점을 찾고 터트릴 수 있습니다.

|  |  |
| --- | --- |
| 헤더 타입 | Response header |
| Forbidden header name | 아니오 |

문법
--
```

Server: <product>
```

지시자
---

<product>

요청을 처리하는 소프트웨어 혹은 하위 제품의 이름

예제
--
```

Server: Apache/2.4.1 (Unix)
```

기술 사양
-----

| 기술 사양 | 제목 |
| --- | --- |
| RFC 7231, 섹션 7.4.2: Server | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `Allow`
Allow
=====

**`Allow`** 헤더는 리소스가 지원하는 메소드 집합을 나열합니다.

어떤 요청 메소드를 사용할 수 있는지 알리기 위해 서버가 `405` `Method Not Allowed` 상태코드로 응답할 경우에 이 헤더를 반드시 보내야 합니다. 비어있는 `Allow` 헤더는 리소스가 어떤 요청 메소드도 허용하지 않음을 나타냅니다. 예를 들어, 특정 리소스에 대해 일시적으로 발생할 수도 있는 요청 메소드조차 허용하지 않음을 나타냅니다.

|  |  |
| --- | --- |
| Header type | Entity header |
| Forbidden header name | no |

구문
--
```

Allow: <http-methods>
```

지시어
---

<http-methods>

쉼표로 구분한 허용된 HTTP request methods 목록.

예제
--
```

Allow: GET, POST, HEAD
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.allow |

더보기
---

* `405`
* `Server`
Referer
=======

**`Referer`** 요청 헤더는 현재 요청을 보낸 페이지의 절대 혹은 부분 주소를 포함합니다. 만약 링크를 타고 들어왔다면 해당 링크를 포함하고 있는 페이지의 주소가, 다른 도메인에 리소스 요청을 보내는 경우라면 해당 리소스를 사용하는 페이지의 주소가 이 헤더에 포함됩니다.`Referer` 헤더는 사람들이 어디로부터 와서 방문 중인지를 인식할 수 있도록 해주며 해당 데이터는 예를 들어, 분석, 로깅, 혹은 캐싱 최적화에 사용될 수도 있습니다.

`Referer` 헤더는 URL 프래그먼트 (예 : "#section") 또는 "username : password" 정보를 포함 할 수 없습니다. *origin*, *경로*, 및 *쿼리 문자열*을 포함 할 수는 있습니다. 전송되는 내용은 요청에 대한 referrer 정책에 따라 다릅니다. 정보 및 예제는 Referrer-Policy를 참조하십시오. 정보 (en-US) 와 예시 (en-US)는 이곳 `Referrer-Policy` (en-US)을 참고하세요.

**참고:** #### Notereferer는 단어 "referrer"의 잘못된 철자입니다. 자세한 내용은 HTTP\_referer을 참고하세요.

**경고:** #### Warning`Referer` 헤더는 사생활과 관련된 브라우징 히스토리에 관한 정보를 노출할 가능성이 있습니다. 더 많은 정보는 Referer header: privacy and security concerns 이곳을 참조하세요.


|  |  |
| --- | --- |
| Header type | Request header |
|

문법
--
```

Referer: <url>
```

디렉티브
----

<url>

현재 요청된 페이지의 링크 이전의 웹 페이지의 절대 혹은 부분 주소. URL 프래그먼트(예를 들어, "#section")나 사용자 정보(예를 들어 "https://username:password@example.com/foo/bar/" 에서 "username:password")는 포함되지 않습니다. 오리진, 패쓰, 쿼리스트링은 referrer 정책 (en-US)에 따라 포함될 수 있습니다.

예제
--
```

Referer: https://developer.mozilla.org/ko/docs/Web/JavaScript
Referer: https://example.com/page?q=123
Referer: https://example.com/
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.referer |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* HTTP\_referer
* Fetch: `Request.referrerPolicy` (en-US)
* outdated 된 `Content-Security-Policy` (en-US) `referrer` (en-US) 
지원이 중단되었습니다
 디렉티브
* Same-origin policy
* Tighter Control Over Your Referrers – Mozilla Security Blog
Content-Location
================

**`Content-Location`** 헤더는 반환된 데이터에 대한 대체 위치을 가르킵니다. 주된 유스케이스는 컨텐츠 협상의 결과로써 전달되는 리소스의 URL을 가르키는 것입니다.

`Location` (en-US)과 `Content-Location`는 다릅니다: `Location` (en-US)가 리다이렉션의 대상(혹은 새롭게 만들어진 문서의 URL)을 가르키는데 반해, `Content-Location`은 더 이상의 컨텐츠 협상없이, 리소스 접근에 필요한 직접적인 URL을 가르킵니다. `Location`은 응답과 연관된 헤더인데 반해, `Content-Location` 은 반환된 개체와 연관이 있습니다.

|  |  |
| --- | --- |
| Header type | Entity header |
| Forbidden header name | no |

문법
--
```

Content-Location: <url>
```

디렉티브
----

<url>

(요청 URL에 대해) 상대적이거나 혹은 절대적인 URL.

예제
--
```

Content-Location: /index.html
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.content-location |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* `Location` (en-US)
If-Unmodified-Since
===================

 HTTP (HyperText Transfer Protocol) **`If-Unmodified-Since`** 요청 헤더는 리소스 요청을 조건부로 설정합니다.
 서버는 이 HTTP 헤더에 지정된 날짜 이후에 리소스가 수정되지 않은 경우에만 요청된 리소스를 보내거나 `POST` 또는 기타 non-safe 메서드에 대한 요청을 승인합니다.
 리소스가 지정된 날짜 이후에 수정된 경우 서버의 응답은 '`412 Precondition Failed` (en-US) 오류가 됩니다.

**`If-Unmodified-Since`** HTTP 헤더는 일반적으로 다음과 같은 상황에서 사용됩니다.

* 이 헤더를 `POST`와 같은 non-safe 메서드와 함께 사용할 경우,
 일부 위키에서 사용하는 것처럼 optimistic concurrency control를 구현할 수 있습니다.
 즉, 원본 문서가 조회된 이후로 수정이 발생한 경우, 새로운 편집은 거부되게 됩니다.
* 이 헤더를 `Range` 헤더와 함께 사용함으로써, 요청된 새로운 조각이 수정되지 않은 문서로부터 제공되었는지 확인할 수 있습니다.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

구문
--


```http
If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

지시어
---

<day-name>

요일에 대한 3글자 설명. "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중에 하나(대소문자 구별).

<day>

해당 월의 2자리 요일 번호입니다. 예: "04" 또는 "23".

<month>

월의 3글자 설명. "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나(대소문자 구별).

<year>

4자리 연도 번호입니다. 예: "1990", "2016".

<hour>

24시간 시스템을 기준으로 한 2자리 시간 숫자입니다. 예: "09", "23".

<minute>

2자리 분 숫자. 예: "04", "59".

<second>

2자리 초 숫자. 예: "04", "59".

`GMT`

그리니치 표준시. HTTP 날짜는 지역 시각이 아닌, 언제나 GMT로 표현합니다.

예제
--


```http
If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # field.if-unmodified-since |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Last-Modified`
* `If-Modified-Since`
* `If-Match` (en-US)
* `If-None-Match`
* `Range`
* `412 Precondition Failed` (en-US)
Retry-After
===========

**`Retry-After`** 응답 HTTP 헤더는 다음에 올 요청이 이루어지기 전에 사용자 에이전트가 대기해야 하는 시간을 가르킵니다. 이 헤더가 사용되는 주요한 두 가지 경우가 있습니다:

* `503` (Service Unavailable) 응답이 전송된 경우, 서비스가 얼마나 오랫동안 이용 불가능한지 예측되는 시간을 가르킵니다.
* `301` (Moved Permanently)와 같은, 리다이렉트 응답이 전송된 경우, 리다이렉트 요청을 하기 이전에 사용자 에이전트가 대기해주길 원하는 최소한의 시간을 가르킵니다.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |

문법
--
```

Retry-After: <http-date>
Retry-After: <delay-seconds>
```

디렉티브
----

<http-date>

해당 시간 이후 재시도하도록 합니다. HTTP 날짜 포맷에 과한 더 자세한 내용은 `Date` 헤더를 참고하시기 바랍니다.

<delay-seconds>

응답이 수신된 이후 지연시키기 위한 초를 가르키는 음수를 불허하는 10진수 정수값입니다.

예제
--

### 예정된 다운타임 다루기

클라이언트와 서버 양측의 `Retry-After` 헤더 지원은 여전히 부조화스럽습니다. 하지만, Googlebot과 같은, 어떤 크롤러와 스파이더들은 `Retry-After` 헤더를 지킵니다. 검색 엔진이 다운타임이 경과한 경우 당신의 사이트에 대한 인덱싱을 유지할 것이기에, `503` (Service Unavailable) 응답에서 해당 헤더를 함께 보내는 것은 유용합니다.
```

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

명세
--

| Specification |
| --- |
| HTTP Semantics # field.retry-after |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)
Forwarded
=========

**`Forwarded`** 헤더는 클라이언트에서 접하고 있는 프록시 서버들이 요청에 대한 연결에 연관되어 있는 상황에서 해당 연결이 변경되거나 잃어버리게 되었을 때, 해당되는 정보를 가지고 있습니다.

이 헤더를 대체하는 실질적인 표준 버전은 `X-Forwarded-For`, `X-Forwarded-Host`, 그리고 `X-Forwarded-Proto` 입니다.

이 헤더는 디버깅, 통계, 그리고 위치 기반 컨텐츠에서 사용되며 클라이언트의 IP 주소와 같은 민감한 개인 정보를 노출하도록 디자인 되었습니다. 따라서 이 헤더를 사용할 경우에는 사용자의 정보를 노출시키지 않도록 반드시 주의해야합니다.

|  |  |
| --- | --- |
| 헤더 타입 | Request header |
| Forbidden header name | 아니오 |

문법
--
```

Forwarded: by=<identifier>; for=<identifier>; host=<host>; proto=<http|https>
```

지시자
---

<identifier>

식별자는 프록시를 사용할 때, 대체되거나 잃어버린 정보를 밝힙니다. 이것은 다음과 같을 수 있습니다:

* IP 주소(v4 또는 v6, 추가로 포트, 그리고 IPv6는 따옴표와 대괄호로 쌓여있습니다),
* 애매한 식별자(예를 들면, "\_hidden" 또는 "\_secret"),
* 또는 알 수 없는 개체를 진행하고자 했을 때 (그리고 당신이 계속 만들어진 요청이 전달되기를 원한다고 알려줄 때) "unknown" or "unknown".

by=<identifier>

요청이 프록시 서버에 들어왔을 때의 인터페이스.

for=<identifier>

요청을 시작한 클라이언트와 프록시 체인에서 뒤이은 프록시.

host=<host>

`Host` 요청 헤더 영역은 프록시에게서 받는다.

proto=<http|https>

요청을 만들기 위해서 어떠한 프로토콜(보통 "http" 또는 "https")이 사용되었는지 알려준다.

예제
--

### `Forwarded` 헤더 사용
```

Forwarded: for="_mdn"

# case insensitive
Forwarded: For="[2001:db8:cafe::17]:4711"

# separated by semicolon
Forwarded: for=192.0.2.60; proto=http; by=203.0.113.43

# multiple values can be appended using a comma
Forwarded: for=192.0.2.43, for=198.51.100.17
```

### `X-Forwarded-For` 에서 `Forwarded` 로의 전환

만약 어플리케이션(서버 또는 프록시)이 표준화된 `Forwared` 헤더를 지원한다면, `X-Forwarded-For` 헤더는 대체될 수 있습니다. IPv6 주소는 `Forwarded`에서 따옴표와 대괄호로 감싸질 수 있다는 것을 알아두세요.
```

X-Forwarded-For: 123.34.567.89
Forwarded: for=123.34.567.89

X-Forwarded-For: 192.0.2.43, 2001:db8:cafe::17
Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
```

기술 사양
-----

| 기술 사양 | 제목 |
| --- | --- |
| RFC 7239, 섹션 4: Forwarded | Forwarded HTTP Extension |

함께 참고할 내용
---------

* `X-Forwarded-For`
* `X-Forwarded-Host`
* `X-Forwarded-Proto`
* `Via` – provides information about the proxy itself, not about the client connecting to it.
Accept
======

**`Accept`** 요청 HTTP 헤더는 MIME 타입으로 표현되는, 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지를 알려줍니다. 컨텐츠 협상을 이용해, 서버는 제안 중 하나를 선택하고 사용하며 `Content-Type` 응답 헤더로 클라이언트에게 선택된 타입을 알려줍니다. 브라우저는 요청이 이루어진 컨텍스트에 따라 해당 헤더에 대해 적당한 값들을 설정합니다: CSS 스타일시트를 불러오게 되면, 이미지, 비디오 혹은 스크립트를 불러올 때와 다른 값이 요청에 대해 설정됩니다.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

문법
--
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Multiple types, weighted with the quality value syntax:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

디렉티브
----

`<MIME_type>/<MIME_subtype>`

`text/html`와 같이 단일의 간격한 MIME 타입.

`<MIME_type>/*`

서버 타입을 갖지 않는 MIME 타입. `image/*` 은 `image/png`, `image/svg`, `image/gif` 그리고 어떤 다른 이미지 타입들과도 일치하게 됩니다.

`*/*`

모든 MIME 타입

`;q=` (q-인자 가중치)

사용되는 모든 값들은 *weight*라고 부르는 상대적인 품질 값을 사용하여 표현되는 선호 순서로 대체됩니다.

예제
--
```

Accept: text/html

Accept: image/*

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

명세
--

| Specification |
| --- |
| HTTP Semantics # field.accept |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

함께 참고할 내용
---------

* HTTP 컨텐츠 협상
* 컨텐츠 현상의 결과에 대한 헤더: `Content-Type`
* 다른 유사한 헤더들: `TE` (en-US), `Accept-Encoding`, `Accept-Charset`, `Accept-Language`
Cross-Origin-Embedder-Policy
============================

HTTP **`Cross-Origin-Embedder-Policy`** (COEP) 응답 헤더는 문서에 교차 출처 리소스를 포함하도록 구성합니다.

|  |  |
| --- | --- |
| 헤더 유형 | Response header |
| Forbidden header name | no |

구문
--


```http
Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless
```

### 지시어

`unsafe-none`

기본값입니다. 문서가 CORS 프로토콜 또는 `Cross-Origin-Resource-Policy` 헤더를 통해 명시적인 권한을 부여하지 않고도 교차 출처 리소스를 가져올 수 있도록 허용합니다.

`require-corp`

문서는 동일한 출처의 리소스 또는 다른 출처에서 불러오기 가능한 것으로 명시적으로 표시된 리소스만 불러올 수 있습니다. 교차 출처 리소스가 CORS를 지원하는 경우, COEP에 의해 차단되지 않고 불러오려면 `crossorigin` 속성 또는 `Cross-Origin-Resource-Policy` 헤더를 사용해야 합니다.

`credentialless` 
Experimental

no-cors (en-US) 교차 출처 요청은 자격 증명 없이 전송됩니다. 특히 요청에서 쿠키가 생략되고 응답에서 쿠키가 무시됩니다. 응답은 `Cross-Origin-Resource-Policy` 헤더를 통해 명시적인 권한 **없이** 허용됩니다. Navigate (en-US) 응답은 `require-corp` 모드와 유사하게 작동합니다. `Cross-Origin-Resource-Policy` 응답 헤더가 필요합니다.

예제
--

### 특정 기능은 교차 출처 격리에 따라 달라집니다

문서에 `require-corp` 또는 `credentialless` 값이 설정된 COEP 헤더가 있는 경우, 스로틀링되지 않은 타이머를 사용하여 `SharedArrayBuffer` 객체나 `Performance.now()` (en-US) 같은 특정 기능에만 접근할 수 있습니다.


```http
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
```


설정해야 하는 `Cross-Origin-Opener-Policy` (en-US) 헤더도 참조하세요.

`crossOriginIsolated` (en-US)가 성공했는지 확인하려면 창 및 작업자 컨텍스트에서 사용할 수 있는 crossOriginIsolated 속성에 대해 테스트하면 됩니다.


```js
const myWorker = new Worker("worker.js");

if (crossOriginIsolated) {
  const buffer = new SharedArrayBuffer(16);
  myWorker.postMessage(buffer);
} else {
  const buffer = new ArrayBuffer(16);
  myWorker.postMessage(buffer);
}
```

### CORS를 통한 COEP 차단 방지

`require-corp`를 사용하여 COEP를 활성화하고 불러와야 하는 교차 출처 리소스가 있는 경우, 해당 리소스는 CORS를 지원해야 하며 다른 출처에서 불러올 수 있는 것으로 명시적으로 표시해야 COEP의 차단을 방지할 수 있습니다. 예를 들어 타사 사이트의 이 이미지에 `crossorigin` 속성을 사용할 수 있습니다.


```html
<img src="https://thirdparty.com/img.png" crossorigin />
```


일부 이미지에 대해 CORS가 지원되지 않는 경우, 쿠키 없이 요청하는 대신 교차 출처 서버에서 명시적인 동의 없이 이미지를 불러오는 대안으로 `credentialless` COEP 값을 사용할 수 있습니다.

명세서
---

| Specification |
| --- |
| HTML Standard # coep |

브라우저 호환성
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

같이 보기
-----

* `Cross-Origin-Opener-Policy` (en-US)