X-Frame-Options - HTTP

X-Frame-Options
===============

The **`X-Frame-Options`** HTTP 응답 헤더는 해당 페이지를 `<frame>` (en-US) 또는`<iframe>` (en-US), `<object>` 에서 렌더링할 수 있는지 여부를 나타내는데 사용됩니다. 사이트 내 콘텐츠들이 다른 사이트에 포함되지 않도록 하여 clickjacking 공격을 막기 위해 이 헤더를 사용합니다.

이 설정은 사용자가 `X-Frame-Options`를 지원하는 브라우저를 통해 페이지에 접근할 경우에만 보안됩니다.

**참고:** `Content-Security-Policy` (en-US) HTTP 헤더에는 브라우저를 지원하기 위해 이 헤더를 사용하지 않도록 하는 `frame-ancestors` (en-US) 지시문이 있습니다.

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

Syntax
------

`X-Frame-Options` 과 관련해서는 다음의 3가지 설정이 가능합니다.
```

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/
```

### Directives

`deny`는 같은 사이트 내에서 frame을 통한 접근도 막습니다.
 `sameorigin`를 명시할 경우에는 frame에 포함된 페이지가 페이지를 제공하는 사이트와 동일한할 경우 계속 사용할 수 있습니다.

`deny`

어떠한 사이트에서도 frame 상에서 보여질 수 없습니다.

`sameorigin`

동일한 사이트의 frame에서만 보여집니다. 해당 스펙 안에서 브라우저 벤더가 최상위(top level), 혹은 부모(parent), 모든 체인(whole chain)에서 적용할지를 결정하도록 맡겨집니다. 하지만 모든 조상(ancestor)이 동일한 사이트에서 제공되지 않으면 이 옵션은 그다지 유용하지 않다고 논의되고 있습니다. (참고 Firefox bug 725490). 상세 지원사항에 대한 참고 Browser compatibility.

`allow-from uri`

지정된 특정 uri의 frame 에서만 보여집니다. Firefox에서는 `sameorigin` 과 동일한 문제를 겪고 있습니다. 즉 동일한 사이트에 있는지에 대해서 frame의 조상(ancestor)을 확인하지 않습니다.

예시
--

**참고:** 메타 테그 설정은 무용지물이다! 이를테면, `<meta http-equiv="X-Frame-Options" content="deny">` 태그는 아무런 영향을 미치지 않는다. 따라서 사용하지 말자! 오직 아래의 예제처럼 HTTP 헤더 설정을 통해서만 `X-Frame-Options`이 동작한다.

### Apache 설정

아파치에서 모든 페이지에 `X-Frame-Options` 헤더를 전송하려면, 사이트 설정에 다음의 설정을 추가합니다.
```

Header always set X-Frame-Options "sameorigin"
```

아파치에서 `X-Frame-Options` 거부(deny)하려면, 사이트 설정에 다음의 설정을 추가합니다.
```

Header set X-Frame-Options "deny"
```

아파치에서 특정 호스트(host)에서 `X-Frame-Options` 를 허용하려면(`allow-from)`, 사이트 설정에 다음의 설정을 추가합니다.
```

Header set X-Frame-Options "allow-from https://example.com/"
```

### nginx 설정

nginx에서 `X-Frame-Options` 헤더를 전송하려면 http, server, location 설정에 아래 설정을 추가합니다.
```

add_header X-Frame-Options sameorigin;
```

### IIS 설정

ISS에서 `X-Frame-Options` 헤더를 전송하려면, 사이트의 `Web.config` 파일에 다음을 추가합니다.

```xml
<system.webServer>
  ...

  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="sameorigin" />
    </customHeaders>
  </httpProtocol>

  ...
</system.webServer>
```

### HAProxy 설정

HAProxy에서 `X-Frame-Options` 헤더를 전송하려면, front-end, listen, 혹은 backend 설정에 다음을 추가합니다.
```

rspadd X-Frame-Options:\ sameorigin
```

명세서
---

| Specification |
| --- |
| HTML Standard # the-x-frame-options-header |

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

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

See also
--------

* ClickJacking Defenses - IEBlog
* Combating ClickJacking with X-Frame-Options - IEInternals
* HTTP Header Field X-Frame-Options - RFC 7034
* CSP Level 2 frame-ancestors directive


Transfer-Encoding - HTTP

Transfer-Encoding
=================

**`Transfer-Encoding`** 헤더는 사용자에게 entity를 안전하게 전송하기 위해 사용하는 인코딩 형식을 지정합니다.

`Transfer-Encoding`은 hop-by-hop 헤더로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용하는 것입니다. 다중-노드 연결의 각각의 세그먼트는 `Transfer-Encoding` 의 값을 다르게 사용할 수 있습니다. 만약 전체 연결에 있어 데이터를 압축하고자 한다면, end-to-end 헤더인 `Content-Encoding` 헤더를 대신 사용하시기 바랍니다.

본문이 없는 `HEAD` 요청에 대한 응답은 그에 대한 `GET` 메시지에 적용될 값을 나타냅니다.

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

구문
--
```

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// 어떤 값들은 쉼표로 구분하여 나열될 수 있습니다
Transfer-Encoding: gzip, chunked
```

디렉티브
----

`chunked`

데이터가 일련의 청크 내에서 전송됩니다. `Content-Length` 헤더는 이 경우 생략되며, 각 청크의 앞부분에 현재 청크의 길이가 16진수 형태로 오고 그 뒤에는 '\r\n'이 오고 그 다음에 청크 자체가 오며, 그 뒤에는 다시 '\r\n'이 옵니다. 종료 청크는 그것의 길이가 0인 것을 제외하면 일반적인 청크와 다르지 않습니다. 그 다음에는 (비어있을수도 있는) 연속된 엔티티 헤더 필드로 구성된 트레일러가 옵니다.

`compress`

Lempel-Ziv-Welch (LZW) 알고리즘을 사용하는 형식. 값의 이름은 이 알고리즘을 구현한, UNIX *compress* 프로그램에서 차용된 것입니다.
 대부분의 UNIX 배포판에서 제외된 압축 프로그램처럼, 이 content-encoding은 어느 정도는 (2003년에 기한이 만료된) 특허 문제로 인해 오늘날 거의 대부분의 브라우저에서 사용되지 않고 있습니다.

`deflate`

(RFC 1951에 정의된) \*deflate \*압축 알고리즘과 함께 (RFC 1950에서 정의된) zlib 구조체를 사용합니다.

`gzip`

32비트 CRC를 이용한 Lempel-Ziv coding (LZ77)을 사용하는 형식. 이것은 근본적으로 UNIX *gzip* 프로그램의 형식입니다. 또한, HTTP/1.1 표준은 이 content-encoding을 지원하는 서버는 호환성 목적을 위해 `x-gzip` 을 별칭으로 인지할 것을 권고하고 있습니다.

`identity`

정체성 기능 (즉, 압축이나 수정이 없는) 을 나타냅니다. 이 토크은 명시적으로 지정되는 경우를 제외하고 항상 허용 가능한 것으로 간주됩니다.

예제
--

### 청크 분할 인코딩

청크 분할 인코딩은 더 많은 양의 데이터가 클라이언트에 전송되고 요청이 완전히 처리되기 전까지는 응답의 전체 크기를 알지 못하는 경우 유용하다. 데이터베이스 쿼리의 결과가 될 큰 HTML 테이블을 생성하는 경우나 큰 이미지를 전송하는 경우가 그 예입니다. 청크 분할 응답은 다음과 같습니다:
```

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n
```

명세
--

| Specification |
| --- |
| HTTP/1.1 # field.transfer-encoding |

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

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

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

* `Accept-Encoding`
* `Content-Encoding`
* `Content-Length`
* Header fields that regulate the use of trailers: `TE` (en-US) (requests) and `Trailer` (en-US) (responses).
* Chunked transfer encoding


Content-Language - HTTP

Content-Language
================

**`Content-Language`** entity header는 청중을 위한 언어를 설명하기 위해 사용되는데, 사용자가 선호하는 언어에 따라 사용자를 구분하도록 해줍니다.

예를 들어, "`Content-Language: de-DE`"가 설정되면, 이는 문서가 독일어 발표자를 위해 만들어졌음을 의미합니다(하지만, 그것이 문서가 독일어로 쓰여졌음을 나타내지는 않습니다. 예를 들어, 독일인 발표자를 위한 언어 코스의 일부분이 영어로 작성된 것일 수도 있습니다).

`Content-Language`이 지정되지 않는다면, 모든 언어의 청중을 위해 만들어진 내용이라고 간주합니다. 다중 언어 태그 또한 가능한데다, 텍스트로 이루어진 문서 뿐만 아니라 여러 가지 미디어 타입에도 `Content-Language` 헤더가 적용됩니다.

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

문법
--
```

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

디렉티브
----

`language-tag`

다중 언어 태그는 쉼표로 구분됩니다. 각 언어 태그는 하이프 문자("`-`", `%x2D`)로 구분되는, 한 개 이상의 대소문자를 구분하지 않는 서브태그의 연속입니다. 대부분의 경우, 언어 태그는 관련 언어군 (예를 들어, "`en`" = English)을 나타내는 주요 언어로 구성되는데, 그 뒤에는 해당 언어의 범위를 정제하거나 좁혀주는 d일련의 서브태그가 올 수 있습니다 (예, "`en-CA`" = 캐나다에서 사용되는 영어의 변종).

**참고:** **알아둘 것:** 언어 태그는 공식적으로 RFC 5646에 정의되어 있으며, 그에 이어 사용될 언어 코드에 대해서 ISO 639 표준이 있습니다(더 정확히는 ISO 639-1 코드 목록).

예제
--

### 문서가 작성된 언어 나타내기

글로벌 `lang` 어트리뷰는 HTML 엘리먼트 상에서 전체 HTML 문서 혹은 그의 일부의 언어를 나타내기 위해 사용됩니다.

```html
<html lang="de"></html>
```

다음과 같이 문서 언어를 나타내기 위해 이와 같은 메타 엘리먼트를 사용하지 **마세요**:

```html
<!-- /!\ This is bad practice -->
<meta http-equiv="content-language" content="de" />
```

### 리소스에 대해 대상 청중 나타내기

`Content-Language` 헤더는 **페이지의 대상 청중**을 지정하는데 사용되며 한 개 이상의 언어를 나태낼 수 있습니다.
```

Content-Language: de, en
```

명세
--

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

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

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

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

* `Accept-Language`
* HTTP 헤더, 메타 엘리먼트 그리고 언어 정보


Access-Control-Allow-Credentials - HTTP

Access-Control-Allow-Credentials
================================

응답헤더 **`Access-Control-Allow-Credentials`** 는 요청의 자격증명 모드(`Request.credentials`)가 "`include`" 일때, 브라우저들이 응답을 프로트엔드 자바스트립트 코드에 노출할지에 대해 알려줍니다.

요청의 자격증명 모드가 (`Request.credentials`)가 "`include`" 일 때, `Access-Control-Allow-Credentials` 값이 `true` 일 경우에만 브라우저들은 프로트엔드 자바스트립트에 응답을 노출 할 것입니다.

자격증명들은 쿠키, authorization 헤더들 또는 TLS 클라이언트 인증서입니다.

사전 요청의 응답으로 사용할 때, 실제 요청에서 자격증명을 이용할 수 있는지에 대해서 알려줍니다. 심플한 `GET` 요청은 사전 요청하지 않으므로, 자격증명과 함께 리소스에 대한 요청이 만들어 지고, 응답에서 리소스와 함께 이 헤더가 없다면 브라우저는 응답을 무시하고 웹 콘텐츠가 전달 되지 않습니다.

`Access-Control-Allow-Credentials` 헤더는 `XMLHttpRequest.withCredentials` (en-US) 속성이나 Fetch API 생성자의`Request()`의 `credentials` 옵션과 함께 작동합니다. 자격 증명이 있는 CORS 요청의 경우, 브라우저가 프런트엔드 JavaScript 코드에 대한 응답을 노출하기 위해서는 서버(Access-Control-Allow-Credentials 헤더 사용)와 클라이언트(XHR, Fetch 또는 Ajax 요청에 대한 자격 증명 모드를 설정하여)가 자격 증명 포함을 선택하고 있음을 표시해야 합니다.

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

구문
--
```

Access-Control-Allow-Credentials: true
```

디렉티브
----

true

이 해더에 유일하게 유효한 값은 `true`(대소문자 구분)입니다. 자격증명이 필요하지 않으면 값을 `false`로 설정하지 말고 이 해더 전체를 생략하세요.

예제
--

Allow credentials:
```

Access-Control-Allow-Credentials: true
```

Using XHR with credentials:

```js
var xhr = new XMLHttpRequest();
xhr.open("GET", "http://example.com/", true);
xhr.withCredentials = true;
xhr.send(null);
```

Using Fetch with credentials:

```js
fetch(url, {
  credentials: "include",
});
```

명세서
---

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-credentials |

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

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

See also
--------

* `XMLHttpRequest.withCredentials` (en-US)
* `Request()`


SourceMap - HTTP

SourceMap
=========

**`SourceMap`** HTTP 응답 헤더는 생성된 코드를 소스맵에 연결해서, 브라우저가 원본 소스를 재구성하여 디버거에서 재구성된 원본을 표시할 수 있도록 합니다.

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

문법
--

```http
SourceMap: <url>
X-SourceMap: <url> (deprecated)
```

### 지시자

<url>

소스 맵 파일을 가리키는 상대적인 URL(요청한 URL 기준) 또는 절대 URL입니다.

예제
--

```http
SourceMap: /path/to/file.js.map
```

명세
--

| Specification |
| --- |
| Source Map # linking-generated-code |

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

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

같이 보기
-----

* Firefox Developer Tools: using a source map


Content-Length - HTTP

Content-Length
==============

**`Content-Length`** 헤더는 수신자에게 전송되는 메시지 본문의 크기(바이트)를 나타냅니다.

|  |  |
| --- | --- |
| 헤더 타입 | 요청 헤더,
 응답 헤더,
 Payload header |
| 금지된 헤더 이름 | 네 |
| CORS-safelisted response header | 네 |

구문
--

```http
Content-Length: <length>
```

지시어
---

<length>

8진수에 대한 십진수 단위의 길이.

명세서
---

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

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

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

같이 보기
-----

* `Transfer-Encoding`


Cross-Origin-Resource-Policy - HTTP

Cross-Origin-Resource-Policy
============================

HTTP **`Cross-Origin-Resource-Policy`** 응답 헤더는 브라우저가 지정된 리소스에 대한 no-cors 교차 출처/사이트 간 요청을 차단하기를 원한다는 뜻을 전달합니다.

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

구문
--

```http
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```

예제
--

아래 응답 헤더를 사용하면 호환되는 사용자 에이전트가 교차 출처 no-cors 요청을 허용하지 않게 됩니다.

```http
Cross-Origin-Resource-Policy: same-origin
```

자세한 예는 https://resourcepolicy.fyi/ 을 참조하세요.

명세서
---

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

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

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

같이 보기
-----

* 교차 출처 리소스 정책(CORP) 설명자 (en-US)
* 교차 출처 리소스 정책 배포 고려하기
* `Access-Control-Allow-Origin`


Content-Encoding - HTTP

Content-Encoding
================

**`Content-Encoding`** 개체 헤더는 미디어 타입을 압축하기 위해 사용됩니다. 이 헤더가 존재하면, 그 값은 개체 본문에 어떤 추가적인 컨텐츠 인코딩이 적용될지를 나타냅니다. 그것은 `Content-Type` 헤더에 의해 참조되는 미디어 타입을 얻도록 디코드하는 방법을 클라이언트가 알게 해줍니다.

가능한 더 많은 데이터를 압축하기 위해 이 필드의 사용이 권고되지만, jpeg 이미지와 같은 어떤 유형의 리소스들은 이미 압축되어 때때로 추가적인 압축이 별 소용이 없고 페이로드를 더 길게 만들수도 있습니다.

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

문법
--
```

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br
```

디렉티브
----

`gzip`

32비트 CRC를 지닌, Lempel-Ziv coding (LZ77)을 사용하는 포맷. 이는 본래 UNIX *gzip* 프로그램의 포맷입니다. HTTP/1.1 표준 역시 이 컨텐츠 인코딩을 지원하는 서버는 호환성 목적으로, `x-gzip` 별칭의 인지가 권고됩니다.

`compress`

Lempel-Ziv-Welch (LZW) 알고리즘을 사용하는 포맷. 그 값의 이름은 이 알고리즘을 구현한 UNIX *compress* 프로그램으로부터 가져왔습니다.
 대부분의 UNIX 배포판으로부터 사라져 왔던 압축 프로그램처럼, 이 content-encoding은 (2013년에 만료된)특허권 이슈로 오늘날의 브라우저에서 사용되지 않습니다.

`deflate`

(RFC 1951에 정의된) *deflate* 압축 알고리즘을 이용한, (RFC 1950에 정의된) zlib 스트럭쳐를 사용합니다.

`identity`

identity 함수를 나타냅니다(즉, 압축 없음 혹은 변경 없음). 이 토큰은, 명시적으로 지정된 경우를 제외하고, 항상 수용 가능하다고 여겨집니다.

`br`

Brotli 알고리즘을 사용하는 포맷.

예제
--

### gzip을 이용해 압축하기

클라이언트 측에서, HTTP 요청 내에 함께 전송될 압축 스킴 목록을 알릴 수 있습니다. `Accept-Encoding` 헤더는 컨텐츠 인코딩 협상을 위해 사용됩니다.
```

Accept-Encoding: gzip, deflate
```

서버는 사용한 스킴을 `Content-Encoding` 응답 헤더에 표시하여 응답합니다.
```

Content-Encoding: gzip
```

서버는 어떤 압축 방법도 사용하도록 강요받지 않는다는 것을 알아두시기 바랍니다. 압축은 서버 설정과 사용되는 서버 모듈에 상당히 의존적입니다.

명세
--

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

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

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

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

* `Accept-Encoding`
* `Transfer-Encoding`


Access-Control-Max-Age - HTTP

Access-Control-Max-Age
======================

**`Access-Control-Max-Age`** 응답 헤더는 preflight request의 결과(즉, `Access-Control-Allow-Methods` 및 `Access-Control-Allow-Headers` 헤더에 포함된 정보)를 얼마나 오래 캐시할 수 있는지를 나타냅니다.

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

구문
--

```http
Access-Control-Max-Age: <delta-seconds>
```

지시어
---

<delta-seconds>

결과를 부호가 없는 음수가 아닌 정수로 캐시할 수 있는 최대 시간(초)입니다. Firefox는 24시간(86400초)으로 제한합니다. 크롬(v76 이전 버전)은 10분(600초)으로 제한됩니다. 크롬(v76부터)은 2시간(7200초)으로 제한됩니다. 기본값은 5초입니다.

예제
--

preflight 요청의 결과를 10분 동안 캐시합니다.

```http
Access-Control-Max-Age: 600
```

명세서
---

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

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

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

같이 보기
-----

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`


Age - HTTP

Age
===

**`Age`** 헤더는 객체가 프록시 캐시 내에 머무는 초단위의 시간을 가집니다.

`Age` 헤더는 보통 0에 가깝습니다. 만약 `Age: 0라면`, 그것은 아마도 원 서버로부터 막 내려받은 것일 겁니다.
 그게 아니라면 프록시의 현재 시간과 HTTP 응답 내에 포함된 `Date` 일반 헤더의 차로 계산됩니다.

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

구문
--

```http
Age: <delta-seconds>
```

지시자
---

`<delta-seconds>`

음수가 아닌 정수형으로, 객체가 프록시 캐시 내에 머문 초단위 시간을 나타냅니다.

예제
--
```

Age: 24
```

명세서
---

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

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

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

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

* `Cache-Control`
* `Expires`


ETag - HTTP

ETag
====

**ETag** HTTP 응답 헤더는 특정 버전의 리소스를 식별하는 식별자입니다. 웹 서버가 내용을 확인하고 변하지 않았으면, 웹 서버로 full 요청을 보내지 않기 때문에, 캐쉬가 더 효율적이게 되고, 대역폭도 아낄 수 있습니다. 허나, 만약 내용이 변경되었다면, "mid-air collisions" 이라는 리소스 간의 동시 다발적 수정 및 덮어쓰기 현상을 막는데 유용하게 사용됩니다.

만약 특정 URL 의 리소스가 변경된다면, 새로운 ETag 가 생성됩니다. ETag 는 지문과 같은 역할을 하면서 다른 서버들이 추적하는 용도에 이용되기도 합니다. ETag 를 비교하여 리소스가 서로 같은지의 여부를 빠르게 판단할 수 있지만, 서버에서 무기한으로 지속될 수 있도록 설정할 수도 있습니다.

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

문법
--
```

ETag: W/"<etag_value>"
ETag: "<etag_value>"
```

참고
--

`W/` Optional

`'W/'` (대/소문자를 구분합니다.) weak validator 가 사용되었음을 나타냅니다. Weak validators 는 만들기는 쉽지만 비교하기에는 효율성이 떨어집니다. Strong validators 는 비교하기에는 이상적이지만 효율적으로 만들기가 어렵습니다. 동일한 자원의 두 가지 Weak `Etag` 값은 동일할 수 있지만, 바이트 단위까지 동일하진 않습니다.

"<etag\_value>"

 Entity tags 는 요청된 값을 ASCII 코드와 같이 고유한 형태로 나타냅니다. (예 : `"675af34563dc-tr34"`)
 `ETag` 의 값을 생성하는 방법(Method)은 단순히 한가지로 정해져있진 않습니다. 때때로, 콘텐츠의 해시, 마지막으로 수정된 타임스탬프의 해시, 혹은 그냥 개정번호를 이용합니다. 예를들어, MDN 는 wiki(콘텐츠)의 16진수 해시를 사용합니다.

예시
--
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### 충돌 피하기 (mid-air collisions)

`ETag`와 HTTP헤더의 `If-Match` (en-US)를 이용하여 충돌을 예측할 수 있습니다.

예를 들어 MDN을 편집할 때, 현재 위키 콘텐츠는 해시되어 `Etag` 안에 들어갑니다.
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4
```

위키 페이지에 변경사항을 저장할 때, `POST`의 요청은 `If-Match` (en-US)헤더에 새로운 변경사항이 발생했는지 판별하기 위해, 기존의 `ETag`값을 포함하여 요청을 진행합니다.
```

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

해시가 일치하지 않으면, 문서가 변경되었다는 의미이며 `412` (en-US) `Precondition Failed` (전제조건 실패) 에러를 던져주게 됩니다.

### 변경되지 않은 리소스의 캐싱

`ETag`의 다른 용례는 변경되지 않은 리소스를 캐시하는 것 입니다. 사용자가 URL을 재방문 했을 때(`ETag`를 가지고 있는 상태에서), 보유한 `ETag`가 너무 오래되어 사용될 수 없다고 판단되면, 클라이언트는 `If-None-Match` 헤더 필드에 `ETag`를 전송합니다.
```

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

서버는 클라이언트의 `ETag`를 현재 버전 리소스의 `ETag`와 비교하고, 두 값이 일치하는 경우(리소스에 변경이 없는 경우) `304` `Not Modified` 상태를 반환합니다. 이 상태는 캐시된 버전이 여전히 유효하다는 것을 클라이언트에게 알려줍니다.

사양
--

| 사양 | 제목 |
| --- | --- |
| RFC 7232, 섹션 2.3: ETag | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

참고
--

* `If-Match` (en-US)
* `If-None-Match`
* `304` `Not Modified`
* `412` (en-US) `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


Vary - HTTP

Vary
====

**`Vary`** HTTP 응답 헤더는 요청 메시지의 메서드 및 URL을 제외하고 응답 내용에 영향을 준 부분을 설명합니다.
 대부분 이 헤더는 콘텐츠 협상이 사용 중일 때
 캐시 키를 생성하는 데 사용됩니다.

`304` `Not Modified` 응답과 "기본" 응답을 포함하여 지정된 URL에 대한 모든 응답에
 동일한 `Vary` 헤더 값을 사용해야 합니다.

|  |  |
| --- | --- |
| 헤더 타입 | 응답 헤더 |
| 금지된 헤더 이름 | 아니오 |

구문
--

```http
Vary: \*
Vary: <header-name>, <header-name>, ...
```

지시어
---

\*

요청 헤더 이외의 요소가 이 응답 생성에 영향을 미쳤음을 나타냅니다. 응답이 캐시할 수 없음을 의미합니다.

<header-name>

응답 생성에 영향을 줄 수 있는 요청 헤더 이름을 쉼표로 구분한 목록입니다.

명세서
---

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

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

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

호환성 노트
------

* Vary with care – Vary header problems in IE6-9
같이 보기
-----

* Understanding The Vary Header - Smashing Magazine
* Best Practices for Using the Vary Header – fastly.com
* 컨텐츠 협상


Authorization - HTTP

Authorization
=============

HTTP **`Authorization`** 요청 헤더는 서버의 사용자 에이전트임을 증명하는 자격을 포함하여, 보통 서버에서 `401` `Unauthorized` 상태를 `WWW-Authenticate` (en-US) 헤더로 알려준 이후에 나옵니다.

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

문법
--
```

Authorization: <type> <credentials>
```

지시자
---

<type>

인증 타입. 보통 타입은 "Basic"이며. 다른 타입으로:

* IANA registry of Authentication schemes
* Authentification for AWS servers (`AWS4-HMAC-SHA256`)

<credentials>

만약 "Basic" 인증 스킴이 사용되었다면, 증명은 다음과 같이 만들어집니다:

* 사용자명과 비밀번호가 콜론을 이용하여 합쳐집니다(`aladdin:opensesame`).
* 그 결과에 대한 문자열을 base64 (en-US) 로 인코딩합니다 (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**참고:** Base64 인코딩은 암호화나 해싱을 의미하지 않습니다! 이 방법은 인증에 대해서 문자를 그대로 보내는 것과 동일하다고 할 수 있습니다 (base64인코딩은 복호화 가능). Basic 인증을 하는 경우 HTTPS로 접속하는 것을 권장합니다.

예제
--
```

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

HTTP basic 인증을 사용하여 비밀번호를 보호하기 위해 Apache 또는 nginx 서버를 어떻게 설정해야 하는지 예제를 보기 위해서는 HTTP authentication 를 보시기 바랍니다.

기술 사양
-----

| 기술 사양 | 제목 |
| --- | --- |
| RFC 7235, 섹션 4.2: Authorization | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

함께 더 보기
-------

* HTTP authentication
* `WWW-Authenticate` (en-US)
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `401`, `403`, `407` (en-US)


X-XSS-Protection - HTTP

X-XSS-Protection
================

HTTP \*\*`X-XSS-Protection`\*\*헤더는 Internet Explorer, Chrome 및 Safari에서 제공하는 기능으로서, (XSS (en-US)) 공격을 감지 할 때 페이지 로드를 중지시킬 수 있습니다. 최신 브라우저에서는 Inline Javascript(`'unsafe-inline')`사용을 못하게 하는 CSP(Content-Security-Policy) 보호기능이 있으나, 해당 기능을 지원하지 않는 구형 웹브라우저에서 사용자를 보호 할수 있는 기능을 제공할 수 있습니다.

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

문법
--
```

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```

0

XSS 필터링을 비활성화합니다.

1

XSS 필터링을 사용합니다 (일반적으로 브라우저의 기본값입니다). 사이트 내에서 스크립팅 공격이 감지되면 브라우저는 안전하지 않은 영역을 제거 후에 렌더링을 하게 됩니다.

1; mode=block

XSS 필터링을 사용합니다. 공격이 탐지되면 안전하지 않는 영역을 제거하는게 아니라, 페이지 렌더링을 중단합니다.

1; report=<reporting-URI> (Chromium에서만 사용 가능)

XSS 필터링을 사용합니다. XSS 공격을 탐지하면 브라우저는 페이지 렌더링을 차단하고 위반 사항을 보고합니다. 이것은 CSP `report-uri` (en-US) 지시문의 기능을 사용하여 보고서를 보냅니다.

예제
--

XSS 공격을 감지하면 페이지로드를 차단합니다.

```bash
X-XSS-Protection: 1; mode=block
```

PHP

```php
header("X-XSS-Protection: 1; mode=block");
```

Apache (.htaccess)

```bash
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```

Nginx

```bash
add_header "X-XSS-Protection" "1; mode=block";
```

명세서
---

#### No specification found

No specification data found for `http.headers.X-XSS-Protection`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

지원 브라우저
-------

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

See also
--------

* `Content-Security-Policy` (en-US)
* Controlling the XSS Filter – Microsoft
* Understanding XSS Auditor – Virtue Security
* The misunderstood X-XSS-Protection – blog.innerht.ml


X-Forwarded-Host - HTTP

X-Forwarded-Host
================

**`X-Forwarded-Host`** (XFH) 헤더는 HTTP 요청 헤더에서 클라이언트가 요청한 원래 `Host` 헤더를 식별하는 사실상의 표준 헤더입니다.

리버스 프록시(로드발란서, CDN) 에서 Host 이름과 포트는 요청을 처리 하는 Origin 서버와 다를 수 있습니다. 이러한 경우 `X-Forwarded-Host` 헤더는 원래 사용된 Host 를 확인 하는데 유용 합니다.

이 헤더는 디버깅, 통계 및 위치 종속 컨텐츠 생성에 사용되며 설계 상 클라이언트의 IP 주소와 같은 개인 정보에 민감한 정보를 노출합니다. 따라서이 헤더가 사용될 때 사용자의 개인 정보를 염두에 두어야합니다.

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

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

문법
--
```

X-Forwarded-Host: <host>
```

지시자
---

<host>

전달된 서버의 도메인 이름.

예제
--
```

X-Forwarded-Host: id42.example-cdn.com
```

기술명세
----

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

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

* `Host`
* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Proto`


Connection - HTTP

Connection
==========

**`Connection`** 일반 헤더는 현재의 전송이 완료된 후 네트워크 접속을 유지할지 말지를 제어합니다. 만약 전송된 값이 `keep-alive`면, 연결은 지속되고 끊기지 않으며, 동일한 서버에 대한 후속 요청을 수행할 수 있습니다.

**경고:** `Connection` 와 `Keep-Alive` 같은 연결-지정(Connection-specific) 헤더 필드들은 HTTP/2.에서 금지되었습니다. 크롬과 Firefox는 HTTP/2 응답에서 그들을 무시하지만, Safari는 HTTP/2 규격 요건에 따라 해당 필드가 포함된 응답은 처리하지 않습니다.

표준 홉 간 헤더인 (`Keep-Alive`, `Transfer-Encoding`, `TE` (en-US), `Connection`, `Trailer` (en-US), `Upgrade` (en-US), `Proxy-Authorization` (en-US) 그리고 `Proxy-Authenticate` (en-US))를 제외하고, 메시지에 의해 사용되는 모든 홉 간 헤더들이 `Connection` 헤더 내에 연결되기에, 첫번째 프록시는 자신이 해당 헤더들을 소비해야 하며 포워드해서는 안된다는 것을 알 게 됩니다. 표준 홉 간 헤더들도 나열될 수 있지만(대게 `Keep-Alive`의 경우가 그렇습니다), 강제적인 것은 아닙니다.

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

문법
--
```

Connection: keep-alive
Connection: close
```

디렉티브
----

`close`

클라이언트 혹은 서버가 연결을 닫으려고 하는 것을 나타냅니다. 이것은 HTTP/1.0 요청에서 기본 값입니다.

쉼표로 구분된 HTTP 헤더 목록 [보통 `keep-alive` 만 해당]

클라이언트가 연결을 열린 상태로 유지하려는 것을 나타냅니다. 영속적인 연결을 가지는 것은 HTTP/1.1 요청의 경우 기본입니다. 헤더 목록은 첫번째 반투명 프록시 혹은 중간 캐시에 의해 제거될 헤더의 이름입니다: 이 헤더들은 목적지 노드가 아닌 (요청) 발행자와 첫번째 개체 사이의 연결을 정의합니다.

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

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


Cache-Control - HTTP

Cache-Control
=============

**`Cache-Control`** 일반 헤더 필드는 요청과 응답 내의 캐싱 메커니즘을 위한 디렉티브를 정하기 위해 사용됩니다. 캐싱 디렉티브는 단방향성이며, 이는 요청 내에 주어진 디렉티브가 응답 내에 주어진 디렉티브와 동일하다는 것을 뜻하지는 않는다는 것을 의미합니다.

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

문법
--

디렉티브는 대소문자를 구분하지 않으며 토큰과 따옴표로 둘러쌓인 문자열 문법 모두를 사용할 수 있는 부가적인 인자를 가집니다. 다중 디렉티브는 쉼표로 구분됩니다.

### 캐시 요청 디렉티브

HTTP 요청 내에서 클라이언트에 의해 사용될 수 있는 표준 `Cache-Control` 디렉티브.
```

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: only-if-cached
```

### 캐시 응답 디렉티브

HTTP 응답 내에서 서버에 의해 사용될 수 있는 표준 `Cache-Control` 디렉티브.
```

Cache-control: must-revalidate
Cache-control: no-cache
Cache-control: no-store
Cache-control: no-transform
Cache-control: public
Cache-control: private
Cache-control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-control: s-maxage=<seconds>
```

### 확장 `Cache-Control` 디렉티브

확장 `Cache-Control` 디렉티브는 핵심 HTTP 캐싱 표준 문서에 속하지 않습니다. 지원 여부는 호환성 테이블을 확인하시기 바랍니다.
```

Cache-control: immutable
Cache-control: stale-while-revalidate=<seconds>
Cache-control: stale-if-error=<seconds>
```

디렉티브
----

### 캐시 능력

`public`

응답이 어떤 캐시에 의해서든 캐시된다는 것을 나타냅니다.

`private`

응답이 단일 사용자를 위한 것이며 공유 캐시에 의해 저장되지 않아야 한다는 것을 나타냅니다. 사설 캐시는 응답을 저장할 수도 있습니다.

`no-cache`

캐시된 복사본을 사용자에게 보여주기 이전에, 재검증을 위한 요청을 원 서버로 보내도록 강제합니다.

`only-if-cached`

새로운 데이터를 내려받지 않음을 나타냅니다. 클라이언트는 캐시된 응답만을 원하며, 더 최신 복사본이 존재하는지를 알아보기 위해 서버에 요청해선 안됩니다.

### 만료

`max-age=<seconds>`

리소스가 최신 상태라고 판단할 최대 시간을 지정합니다. `Expires`에 반해, 이 디렉티브는 요청 시간과 관련이 있습니다.

`s-maxage=<seconds>`

`max-age` 혹은 `Expires` 헤더를 재정의하나, (프록시와 같은) 공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.

`max-stale[=<seconds>]`

클라이언트가 캐시의 만료 시간을 초과한 응답을 받아들일지를 나타냅니다. 부가적으로, 초 단위의 값을 할당할 수 있는데, 이는 응답이 결코 만료되서는 안되는 시간을 나타냅니다.

`min-fresh=<seconds>`

클라이언트가 지정된 시간(초단위) 동안 신선한 상태로 유지될 응답을 원한다는 것을 나타냅니다.

`stale-while-revalidate=<seconds>`
Experimental

비동기 적으로 백그라운드 에서 새로운 것으로 체크인하는 동안 클라이언트가 최신이 아닌 응답을 받아 들일 것임을 나타냅니다. 초 값은 클라이언트가 최신이 아닌 응답을 받아 들일 시간을 나타냅니다.

`stale-if-error=<seconds>`
Experimental

...

### 재검증과 리로딩

`must-revalidate`

캐시는 사용하기 이전에 기존 리소스의 상태를 반드시 확인해야 하며 만료된 리소스는 사용되어서는 안됩니다.

`proxy-revalidate`

`must-revalidate`와 동일하지만, (프록시와 같은)공유 캐시에만 적용되며 사설 캐시에 의해서는 무시됩니다.

`immutable`

응답 본문이 계속해서 변하지 않을 것이라는 것을 나타냅니다. 응답은, 만료되지 않은 경우라면, 서버 상에서 변경되지 않을 것이고 그러므로 클라이언트는 업데이트 검사를 위해 (`If-None-Match` 혹은 `If-Modified-Since`과 같은)그에 대한 조건부의 재검증을 전송해서는 안 됩니다. 이 확장을 감지하지못한 클라이언트는 HTTP 명세에 따라 그것들을 무시해야만 합니다. Firefox에서, `immutable`는 `https://` 트랜잭션 상에서만 부여됩니다. 좀 더 많은 정보는 다음의 블로그 포스트를 참고하시기 바랍니다.

### 기타

`no-store`

캐시는 클라이언트 요청 혹은 서버 응답에 관해서 어떤 것도 저장해서는 안됩니다.

`no-transform`

응답에 대해 변형이나 변환이 일어나서는 안됩니다. Content-Encoding, Content-Range, Content-Type 헤더는 프록시에 의해서 수정되어서는 안됩니다. 반투명 프록시는, 예를 들어, 캐시 공간을 절약하고 느린 링크 상의 트래픽량을 줄이기 위해 이미지 포맷들을 변환합니다. `no-transform` 디렉티브는 이를 허용하지 않습니다.

예제
--

### 캐싱 막기

캐싱을 끄기 위해서, 다음의 디렉티브들을 보낼 수 있습니다. 추가로, `Expires와` `Pragma` 헤더를 참고하시기 바랍니다.

```bash
Cache-Control: no-cache, no-store, must-revalidate
```

### 정적 에셋 캐싱

변경되지 않을 애플리케이션 내 파일들에 대해, 보통 적극적인 캐싱을 추가할 수 있습니다. 이것은 예를 들자면, 이미지, CSS 파일 그리고 JavaScript 파일과 같이 애플리케이션에 의해 서브되는 정적 파일들을 포함합니다. 추가로, `Expires` 헤더를 참고하시기 바랍니다.

```bash
Cache-Control:public, max-age=31536000
```

명세
--

| Specification |
| --- |
| HTTP Caching # field.cache-control |
| HTTP Immutable Responses # the-immutable-cache-control-extension |

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

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

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

* HTTP Caching FAQ (en-US)
* `Age`
* `Expires`
* `Pragma`


Accept-Charset - HTTP

Accept-Charset
==============

**경고:** 이 헤더를 사용하지 마십시오. 브라우저는 이 헤더를 생략하고 서버는 이를 무시해야 합니다.

**`Accept-Charset`** 요청 HTTP 헤더는 클라이언트가 지원하는 문자 인코딩을 알리는 헤더였습니다. 이는 더 이상 널리 사용되지 않습니다.

현재는 UTF-8이 잘 지원되고 있고 문자 인코딩을 위해 압도적으로 선호되는 선택입니다. 더 적은 설정 기반의 엔트로피(불확실성)를 통해 좀 더 나은 개인정보 보호를 보장하기 위해, 모든 브라우저들은 `Accept-Charset` 헤더를 생략합니다. Chrome, Firefox, Internet Explorer, Opera, Safari는 이 헤더를 폐기했습니다.

오늘날 `Accept-Charset`은 널리 알려진 금지된 헤더 중 하나입니다.

|  |  |
| --- | --- |
| 헤더 타입 | 요청 헤더 |
| 금지된 헤더 | 예 |

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

* HTTP 컨텐츠 협상
* Accept-Charset is no more
* 컨텐츠 협상 결과를 이용하는 헤더: `Content-Type`
* 다른 유사한 헤더들: `TE` (en-US), `Accept-Encoding`, `Accept-Language`, `Accept`


Content-Type - HTTP

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`


Content-Disposition - HTTP

Content-Disposition
===================

 일반적인 HTTP 응답에서 **`Content-Disposition`** 헤더는 컨텐츠가 브라우저에 *inline* 되어야 하는 웹페이지 자체이거나 웹페이지의 일부인지, 아니면 *attachment*로써 다운로드 되거나 로컬에 저장될 용도록 쓰이는 것인지를 알려주는 헤더입니다.

`multipart/form-data` 본문에서의 **`Content-Disposition`** 일반 헤더는 multipart의 하위파트에서 활용될 수 있는데, 이 때 이 헤더는 multipart 본문 내의 필드에 대한 정보를 제공합니다. multipart의 하위파트는 `Content-Type` 헤더에 정의된 *boundary* 구분자에 의해 구분되며, `Content-Disposition` 헤더를 multipart 자체에 사용하는 것은 아무런 효과를 발휘하지 못합니다.

`Content-Disposition` 헤더는 광의의 MIME 맥락 속에서 정의되었는데, 그 정의에서 사용되는 파라미터 중 일부인 `form-data`, `name` 그리고 `filename`만이 HTTP forms와 `POST` 요청에 적용될 수 있습니다. 여기서 `name`과 `filename`은 필수적인 파라미터는 아닙니다.

|  |  |
| --- | --- |
| Header type | Response header (for the main body)General header
 (for a subpart of a multipart body)
  |
| Forbidden header name | no |

Syntax (구문)
-----------

### As a response header for the main body (메인 바디를 위한 응답 헤더로서)

HTTP 구문의 첫번째 파라미터는 `inline` (기본값, 웹 페이지 안에서 또는 웹 페이지로 나타남) 또는 `attachment` (반드시 다운로드 받아야 하며 대부분의 브라우저는 'Save as'(새이름으로저장)창을 보여주고 `filename` 파라미터들이 존재한다면 그 이름을 새이름으로 미리 채워줌)입니다.
```

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

### As a header for a multipart body (멀티파트 바디를 위한 헤더로서)

HTTP 구문의 첫번째 파라미터는 언제나 `form-data`입니다. 추가적인 파라미터들은 대소문자 구분이 없으며, `'='` 다음에 "문자열로 표현한 아규먼트들"을 가집니다. 다중 파라미터들은 세미콜론 (`';'`)으로 구분합니다.
```

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### Directives (지시자들)

* `name`
    + : 이름(`name`) 다음에 오는 문자열에는 이 서브파트가 참조하는 폼의 HTML 필드에서 사용한 그 이름이 들어갑니다. 같은 필드에 여러개의 파일이 있을 경우 (예 : `<input type="file"> (en-US)` 요소의 `multiple` (en-US) 속성), 같은 이름으로 여러개의 서브파트들이 존재할 수 있습니다.`name`의 값이 `'_charset_'`인 것은 그 부분이 HTML필드가 아니라, charset을 명시하지 않고 사용할 수 있는 기본 charset임을 나타냅니다.
* `filename`
    + : 파일명(`filename`) 다음에 오는 문자열에는 전송된 해당 파일의 원래 이름이 들어갑니다. 파일명은 언제나 선택사항이지만, 맹목적으로 쓰여서는 안됩니다 : 경로 정보가 공개되어야 하며, 서버 파일 시스템 규칙에 따라 전환되어야 합니다. 이러한 파라미터들은 대부분 지시적 정보(indicative information)를 제공합니다. 파일명이 `Content-Disposition: attachment`과 같이 사용되면 최종적으로 사용자가 "새이름으로저장(Save As)" 창에서 보게 되는 파일명의 기본값으로 사용됩니다.
* `filename*`
    + : "filename"과의 유일한 차이점은 "filename\*"는 인코딩으로 RFC 5987을 사용한다는 것 뿐입니다. 하나의 헤더 필드에 "filename"과 "filename\*"이 둘 다 사용된다면 "filename\*"이 보다 우선됩니다.
Examples
--------

A response triggering the "Save As" dialog:
```

200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 21

<HTML>Save me!</HTML>
```

This simple HTML file will be saved as a regular download rather than displayed in the browser. Most browsers will propose to save it under the `cool.html` filename (by default).

An example of an HTML form posted using the `multipart/form-data` format that makes use of the `Content-Disposition` header:
```

POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

명세서
---

| Specification |
| --- |
| Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) # header.field.definition |
| Returning Values from Forms: multipart/form-data # section-4.2 |

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

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

Compatibility notes
-------------------

* Firefox 5 handles the `Content-Disposition` HTTP response header more effectively if both the `filename` and `filename*` parameters are provided; it looks through all provided names, using the `filename*` parameter if one is available, even if a `filename` parameter is included first. Previously, the first matching parameter would be used, thereby preventing a more appropriate name from being used. See Firefox bug 588781.
See also
--------

* HTML Forms (en-US)
* The `Content-Type` defining the boundary of the multipart body.
* The `FormData` interface used to manipulate form data for use in the `XMLHttpRequest` API.


Expires - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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 - HTTP

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

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 - HTTP

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 - HTTP

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 - HTTP

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
============================

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)


Last-Modified - HTTP

Last-Modified
=============

**`Last-Modified`** 응답 HTTP 헤더에는 원본 서버가 리소스가 마지막으로 수정되었다고 생각하는
 날짜와 시간이 포함되어 있습니다. 이 헤더는 리소스가 이전에 저장된 리소스와 동일한지 확인하기 위한 유효성 검사기로 사용됩니다.
 `ETag` 헤더보다 정확하진 않지만 이 태그는 대비책으로 사용합니다.
 `If-Modified-Since` 또는 `If-Unmodified-Since`헤더를
 포함하는 조건부 요청은 이 필드를 사용합니다.

`Last-Modified`는 크롤러가 크롤링 빈도를 조정할 때,
 브라우저가 휴리스틱 캐싱을 할 때,
 콘텐츠 관리 시스템(CMS)이 콘텐츠가 마지막으로 수정된 시간을 표시할 때에도 사용됩니다.

|  |  |
| --- | --- |
| 헤더 타입 | Representation header |
| 금지된 헤더 이름 | 아니오 |
| CORS-safelisted response header | 예 |

구문
--

```http
Last-Modified: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

지시어
---

<day-name>

"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중 하나(대소문자 구분).

<day>

2 숫자의 날짜, 예: "04" 또는 "23".

<month>

"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나(대소문자 구분).

<year>

4 숫자의 연도, 예: "1990" 또는 "2016".

<hour>

2 숫자의 시간, 예: "09" 또는 "23".

<minute>

2 숫자의 분, 예: "04" 또는 "59.

<second>

2 숫자의 초, 예: "04" 또는 "59".

`GMT`

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

예제
--

```http
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # field.last-modified |

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

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

같이 보기
-----

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`


If-None-Match - HTTP

If-None-Match
=============

**`If-None-Match`** HTTP 요청 헤더는 요청을 조건부로 만듭니다. `GET` 및 `HEAD` 메서드의 경우, 서버는 요청된 리소스에 주어진 값과 일치하는 `ETag`가 없는 경우에만 `200` 상태와 함께 요청된 리소스를 반환합니다. 다른 메서드의 경우, 최종적으로 존재하는 리소스의 `ETag`가 나열된 값 중 어느 것과도 일치하지 않는 경우에만 요청이 처리됩니다.

`GET` 및 `HEAD` 메서드에서 조건이 실패하면 서버는 HTTP 상태 코드 304(Not Modified)를 반환해야 합니다. 서버 측 변경 사항을 적용하는 메서드의 경우 상태 코드 412(Precondition Failed)가 사용됩니다. 304 응답을 생성하는 서버는 동일한 요청에 대해 200(OK) 응답으로 전송되는 다양한 헤더 필드(Cache-Control, Content-Location, Date, ETag, Expires 등) 중 하나를 생성해야 합니다.

저장된 `ETag`와의 비교는 약한 비교 알고리즘을 활용하므로, 콘텐츠가 같다면 두 파일이 바이트 단위로 완전히 일치하지 않아도 동일하다고 판단합니다. 예를 들어, 푸터(footer)의 생성 날짜가 다른 두 페이지는 여전히 동일하다고 판단합니다.

서버에서 지원한다면, `If-Modified-Since`와 함께 사용할 경우 **`If-None-Match`** 가 우선 적용됩니다.

두 가지 일반적인 사용 사례가 있습니다.

* `GET` 및 `HEAD` 메서드의 경우, 연결된 `ETag`가 있는 캐시된 개체를 업데이트합니다.
* 다른 메서드, 특히 `PUT`의 경우, `If-None-Match`가 `*` 값과 함께 사용되면 이는 아직 생성되지 않은 것으로 알려진 파일을 저장하는 데 활용될 수 있으며, 이전에 다른 업로드가 발생하지 않았다는 것을 보장합니다. 더불어 이전에 업로드한 데이터가 손실될 수 있으며 이 문제는 lost update problem의 한 형태입니다.

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

구문
--

```http
If-None-Match: "<etag\_value>"
If-None-Match: "<etag\_value>", "<etag\_value>", …
If-None-Match: \*
```

지시어
---

<etag\_value>

개체 태그는 요청된 리소스를 고유하게 식별합니다. 이는 큰따옴표 사이에 위치한 ASCII 문자열로 표현되며(예: `"675af34563dc-tr34"`), 앞에 `W/`를 추가하여 약한 비교 알고리즘의 사용이 필요함을 나타낼 수 있습니다(`If-None-Match`에서는 해당 알고리즘만을 사용하므로 무의미합니다).

`*`

별표(asterisk)는 리소스를 나타내는 특수 값입니다. 이는 리소스를 업로드할 때, 특히 `PUT`을 사용하여, 동일한 식별자를 가진 다른 리소스가 이미 업로드되었는지를 확인할 때에만 유용합니다.

예제
--

```http
If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-None-Match: W/"67ab43", "54ed21", "7892dd"

If-None-Match: \*
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # field.if-none-match |

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

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

같이 보기
-----

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-Match` (en-US)
* `304 Not Modified`
* `412 Precondition Failed` (en-US)


Access-Control-Request-Headers - HTTP

Access-Control-Request-Headers
==============================

요청 헤더 **`Access-Control-Request-Headers`** 는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 preflight request를 발급(issue)할 때 사용됩니다.

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

구문
--
```

Access-Control-Request-Headers: <header-name>, <header-name>, ...
```

지시어
---

`<header-name>`

요청에 포함 된 HTTP headers의 쉼표로 구분 한 목록.

예제
--
```

Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

명세
--

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

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

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

더보기
---

* `Access-Control-Request-Method`


Date - HTTP

Date
====

**`Date`** 일반 HTTP 헤더는 메시지가 만들어진 날짜와 시간을 포함합니다.

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

문법
--
```

Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

디렉티브
----

<day-name>

"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 혹은 "Sun" 중 하나 (대소문자 구분).

<day>

2자리의 일자 번호, 예를 들어 "04" 혹은 "23".

<month>

"Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" 중 하나 (대소문자 구분).

<year>

4자리의 연도 번호, 예를 들어, "1990" 혹은 "2016".

<hour>

2자리의 시간 번호, 예를 들어, "09" 혹은 "23".

<minute>

2자리의 분 번호, 예를 들어, "04" 혹은 "59".

<second>

2자리의 초 번호, 예를 들어, "04" 혹은 "59".

GMT

Greenwich 표준시. HTTP에서 날짜는 항상 지역 시간이 아닌 GMT로 표현됩니다.

예제
--
```

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

명세
--

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

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

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

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

* `Age`


Accept-Encoding - HTTP

Accept-Encoding
===============

**`Accept-Encoding`** 요청 HTTP 헤더는, 보통 압축 알고리즘인, 클라이언트가 이해 가능한 컨텐츠 인코딩이 무엇인지를 알려줍니다. 컨텐츠 협상을 사용하여, 서버는 제안된 내용 중 하나를 선택하고 사용하며 `Content-Encoding` 응답 헤더를 이용해 선택된 것을 클라이언트에게 알려줍니다.

클라이언트와 서버 모두 동일한 압축 알고리즘을 지원한다고 해도, 식별 값 또한 수용 가능하다면, 서버는 응답의 본문을 압축하지 않으려고 할 수 있습니다. 두 가지 일반적인 경우가 이런 일을 초래합니다:

* 전송되어야 할 데이터가 이미 압축되어 있고 두번째 압축이 전송해야 할 데이터를 더 작게 만들지 못할 경우가 있습니다. 이런 경우는 이미지 포맷 압축에 해당되는 경우가 많습니다;
* 서버에 과부하가 걸리고 압축 요구사항에 의해 초래된 연산의 오버헤드를 감당할 수 없는 경우가 있습니다. 일반적으로, Microsoft는 서버가 자신의 연산력의 80% 이상을 사용하는 경우 압축하지 않을 것을 권고하고 있습니다.

부호화(encoding)되지 않았음을 의미하는, `identity` 값이 식별에 대한 다른 명시적인 설정 값 없이 `identity;q=0` or a `*;q=0`에 의해 명시적으로 숨겨지지 않는 한, 서버는 `406` `Acceptable` 오류를 회신해서는 결코 안됩니다.

**참고:** **Notes:**- IANA 레지스트리는 공식적인 컨텐츠 인코딩의 전체 목록을 운영 중입니다.

* 두 개의 다른 컨텐츠 인코딩, `bzip`과 `bzip2`이 표준은 아니지만 때때로 사용되기도 합니다. 그들은 두 개의 UNIX 프로그램에 의해 사용되는 알고리즘을 구현합니다. 첫번째 알고리즘은 특허 라이선스 문제 때문에 더 이상 유지되지 않는다는 것을 알아두시기 바랍니다.

|  |  |
| --- | --- |
| 헤더 타입 | Request header |
| Forbidden header name | yes |

문법
--
```

Accept-Encoding: gzip
Accept-Encoding: compress
Accept-Encoding: deflate
Accept-Encoding: br
Accept-Encoding: identity
Accept-Encoding: *

// Multiple algorithms, weighted with the quality value syntax:
Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
```

디렉티브
----

`gzip`

32비트 CRC와 함께 Lempel-Ziv coding (LZ77)를 사용하는 압축 포맷.

`compress`

Lempel-Ziv-Welch (LZW) 알고리즘을 사용하는 압축 포맷.

`deflate`

\*deflate \*압축 알고리즘과 함께 zlib 구조를 사용하는 압축 포맷.

`br`

Brotli 알고리즘을 사용하는 압축 포맷.

`identity`

식별 함수(압축하지 않거나 수정하지 않은 경우)를 가리킵니다. 이 값은 존재하지 않은 경우에도 항상 수용 가능하다고 여겨집니다.

`*`

헤더 내에 아직 나열되지 않은 컨텐츠 인코딩이라도 일치됩니다. 헤더가 존재하지 않을 경우, 기본값이 됩니다. 그것이 모든 알고리즘이 지원된다는 것을 의미하지는 않습니다; 단지 표현된 선호 대상이 없다는 것을 의미합니다.

`;q=` (q값 가중치)

*weight*라고 부르는 상대적인 퀄리티 값을 사용하여 표현한 선호도에 따라 배치된 값입니다.

예제
--
```

Accept-Encoding: gzip

Accept-Encoding: gzip, compress, br

Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
```

명세
--

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

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

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

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

* HTTP 컨텐츠 협상
* 컨텐츠 협상의 결과를 이용한 헤더: `Content-Encoding`
* 다른 유사한 헤더들: `TE` (en-US), `Accept`, `Accept-Charset`, `Accept-Language`


Access-Control-Request-Method - HTTP

Access-Control-Request-Method
=============================

요청 헤더 **Access-Control-Request-Method**는 실제 요청이 만들어질 때 클라이언트가 보낼 수도 있는 HTTP headers를 서버에게 알리기 위해 브라우저가 preflight request를 발급(issue)할 때 사용됩니다. 사전 요청(preflight request)은 항상 `OPTIONS`이며 실제 요청과 동일한 메소드를 사용하지 않으므로 이 헤더가 필요합니다.

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

구문
--
```

Access-Control-Request-Method: <method>
```

지시어
---

`<method>`

HTTP request methods 중 하나. 예를 들어 `GET`, `POST`, 또는 `DELETE`.

예제
--
```

Access-Control-Request-Method: POST
```

명세
--

| Specification |
| --- |
| Fetch Standard # http-access-control-request-method |

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

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

더보기
---

* `Access-Control-Request-Headers`


Origin - HTTP

Origin
======

**`Origin`** request 헤더는 fetch가 시작되는 위치입니다. 경로 정보는 포함하지 않고 서버 이름만 포함합니다. `POST` requests에 포함되는 것처럼, CORS requests 와 함께 전송합니다. `Referer` 헤더와 비슷하지만, origin 헤더는 전체 경로를 공개하지 않습니다.

**참고:** **주의**: `HEAD` 와 `GET` 메서드를 통해 `fetch()`를 사용할 때 `Origin` 헤더가 설정되지 않았습니다. (이 문제는 Firefox 65에서 수정되었습니다 — Firefox bug 1508661참조).

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

문법
--
```

Origin: null
Origin: <scheme> "://" <hostname> [ ":" <port> ]
```

지시
--

<scheme>

사용하는 프로토콜. 일반적으로 HTTP 프로토콜 혹은 보안 버전인 HTTPS를 사용합니다.

<hostname>

서버(가상 호스팅)의 이름 또는 IP 입니다.

<port> Optional

서버와 연결을 맺기 위한 TCP 포트 번호. 포트번호를 입력하지 않으면, 요청한 서비스의 기본 포트(HTTP의 경우 "80")가 사용됩니다.

예제
--
```

Origin: https://developer.mozilla.org
```

명세
--

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

브라우저 적합성
--------

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

See also
--------

* `Host`
* `Referer`
* Same-origin policy


Cookie - HTTP

Cookie
======

**`Cookie`** HTTP 요청 헤더는 `Set-Cookie` (en-US) 헤더와 함께 서버에 의해 이전에 전송되어 저장된 HTTP cookies를 포함합니다.

`Cookie` 헤더는 선택적(optional)이고, 만약 브라우저의 사생활 보호 설정(privacy settings)이 쿠키를 block할 경우 생략될 수도 있습니다.

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

문법
--
```

Cookie: <cookie-list>
Cookie: name=value
Cookie: name=value; name2=value2; name3=value3
```

<cookie-list>

`<cookie-name>=<cookie-value>` 형태를 띄는 이름-값 쌍의 목록입니다. 목록 내 쌍들은 세미콜록과 공백(`'; '`)으로 구분됩니다.

예제
--
```

Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;
```

명세
--

| Specification |
| --- |
| HTTP State Management Mechanism # cookie |

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

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

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

* `Set-Cookie` (en-US)
* `Document.cookie` (en-US)


If-Range - HTTP

If-Range
========

**`If-Range`** HTTP 요청 헤더는 범위 요청을 조건적으로 만듭니다: 만약 조건이 만족된다면, 범위 요청은 처리되어 서버에서 `206` `Partial Content` 응답을 적절한 바디를 포함하여 보낼 것입니다. 만약 조건을 만족하지 못한다면, `200` `OK` 상태 코드가 전체 리소스와 함께 돌아올 것입니다.

이 헤더는 `Last-Modified` 유효 검사자, 또는 `ETag`와도 함께 사용될 수 있지만, 동시에는 사용할 수 없습니다.

가장 많은 사용 예로 다운로드를 재개할 때, 저장된 리소스가 마지막 조각을 다운받은 후 수정되었는지 확인하기 위하여 사용합니다.

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

문법
--
```

If-Range: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
If-Range: <etag>
```

지시자
---

<etag>

개체 태그는 요청한 리소스가 유일한 것을 표현합니다. 이는 ASCII 문자열로 쌍따옴표(`"675af34563dc-tr34"`처럼)로 묶여있으며, 접두사로 `W/`가 있어 약한 비교 알고리즘을 사용되어야 하는 것을 알려줄 수 있습니다.

<day-name>

"Mon", "Tue", "Wed", "Thu", "Fri", "Sat", 또는 "Sun" 중에 하나(대소문자 구별) .

<day>

2 숫자의 날짜, 예: "04" 또는 "23".

<month>

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

<year>

4 숫자의 연도, 예: "1990" 또는 "2016".

<hour>

2 숫자의 시간, 예: "09" 또는 "23".

<minute>

2 숫자의 분, 예: "04" 또는 "59".

<second>

2 숫자의 초, 예: "04" 또는 "59.

`GMT`

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

예제
--
```

If-Range: Wed, 21 Oct 2015 07:28:00 GMT
```

기술 사양
-----

| 기술 사양 | 제목 |
| --- | --- |
| RFC 7233, 섹션 3.2: If-Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

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

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

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

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match` (en-US)
* `If-None-Match`
* `206` `Partial Content`
* HTTP Conditional Requests


CSP: script-src - HTTP

CSP: script-src
===============

HTTP `Content-Security-Policy` (en-US) (CSP) **`script-src`** 는 JavaScript에 대한 검증된 출처를 지정합니다. 여기에는 `<script>` 요소에서 직접 호출한 URL뿐만 아니라, 인라인 스크립트 이벤트 핸들러(`onclick`) 및 스크립트를 실행할 수 있는 XSLT stylesheets 가 포함됩니다.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

하나 이상의 출처가 `script-src` 정책에 의해서 허용될 수 있습니다:
```

Content-Security-Policy: script-src <source>;
Content-Security-Policy: script-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values (en-US).

Note that this same set of values can be used in all fetch directives (and a number of other directives (en-US)).

예제
--

### Violation case

주어진 CSP 헤더:

```bash
Content-Security-Policy: script-src https://example.com/
```

아래 스크립트가 차단되어서 로드 또는 실행되지 않습니다:

```html
<script src="https://not-example.com/js/library.js"></script>
```

인라인 스크립트도 실행되지 않습니다:

```html
<button id="btn" onclick="doSomething()"></button>
```

`addEventListener`를 호출하는 것으로 대체해야 합니다.:

```js
document.getElementById("btn").addEventListener("click", doSomething);
```

### 안전하지 않은 인라인 스크립트

**참고:** 인라인 스타일 및 인라인 스크립트를 허용하지 않는 것이 CSP가 제공하는 가장 큰 보안 이점 중 하나 입니다. 그러나, 인라인 스크립트 및 스타일을 사용해야만 한다면 몇가지 방법을 제공합니다.

인라인 스크립트 및 인라인 이벤트 핸들러를 허용하려면, `'unsafe-inline'`, 인라인 태그에 정의한 값과 동일한 nonce-source 또는 hash-source를 지정할 수 있습니다.

```bash
Content-Security-Policy: script-src 'unsafe-inline';
```

위의 CSP는 `<script>` 태그를 허용합니다

```html
<script>
 var inline = 1;
</script>
```

nonce-source를 사용하면 특정 인라인 스크립트 태그만 허용 할 수 있습니다:

```bash
Content-Security-Policy: script-src 'nonce-2726c7f26c'
```

`<script>` 태그에 동일한 nonce를 설정해야 합니다 :

```html
<script nonce="2726c7f26c">
 var inline = 1;
</script>
```

또는, 인라인 스크립트에서 해시를 설정할 수 도 있습니다. CSP는 sha256, sha384 and sha512를 지원합니다.

```bash
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
```

해시를 생성할 때에는 `<script>` 태그를 포함하지 말고, 대소문자, 태그의 앞뒤 공백이 포함되어야 하는 것을 유의해주십시요.

```html
<script>
 var inline = 1;
</script>
```

### 안전하지 않은 eval 표현식

`'unsafe-eval'` 출처 표현식은 문자열에서 코드를 생성하는 여러 스크립트 실행 메소드를 제어합니다. 만약`'unsafe-eval'` 이 `script-src` 에 정의되어 있지 않으면, 아래믜 명령어는 차단되며 아무런 효과가 일어나지 않습니다.

* `eval()`
* `Function()`
* 아래와 같이 문자열 리터럴을 전달할 때 :
 `window.setTimeout("alert(\"Hello World!\");", 500);`
    + `window.setTimeout` (en-US)
    + `window.setInterval` (en-US)
    + `window.setImmediate` (en-US)
* `window.execScript`
비표준
 (IE < 11 only)
### `strict-dynamic`

The `'strict-dynamic`' source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any whitelist or source expressions such as `'self'` or `'unsafe-inline'` will be ignored. For example, a policy such as `script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/` would allow loading of a root script with `<script nonce="R4nd0m" src="https://example.com/loader.js">` and propogate that trust to any script loaded by `loader.js`, but disallow loading scripts from `https://whitelisted.com/` unless accompanied by a nonce or loaded from a trusted script.

```bash
script-src 'strict-dynamic' 'nonce-someNonce'
```

*Or:*

```bash
script-src 'strict-dynamic' 'sha256-base64EncodedHash'
```

 It is possible to deploy `strict-dynamic` in a backwards compatible way, without requiring user-agent sniffing.
 The policy:

```bash
script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
```

will act like`'unsafe-inline' https:` in browsers that support CSP1, `https: 'nonce-abcdefg'` in browsers that support CSP2, and `'nonce-abcdefg' 'strict-dynamic'` in browsers that support CSP3.

명세서
---

| Specification |
| --- |
| Content Security Policy Level 3 # directive-script-src |

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

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

See also
--------

* `Content-Security-Policy` (en-US)
* `<script>`


report-to - HTTP

report-to
=========

`Report-To` HTTP 응답 해더 필드는 사용자 에이전트(브라우저)가 레포트를 저장하기 위한 origin의 엔드포인트를 지정합니다.
```

Content-Security-Policy: ...; report-to groupname
```

이 지시어 자체로는 효과는 없지만 다른 지시문과 조합하여 의미를 가질 수 있습니다.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Reporting directive |
|
 This directive is not supported in the `<meta>`
 element.
  |

Syntax
------
```

Content-Security-Policy: report-to <json-field-value>;
```

Examples
--------

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

더 자세한 정보와 예제는 `Content-Security-Policy-Report-Only` (en-US) 를 확인하세요.
```

Report-To: { "group": "csp-endpoint",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/csp-reports" }
             ] },
           { "group": "hpkp-endpoint",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/hpkp-reports" }
             ] }
Content-Security-Policy: ...; report-to csp-endpoint
```

```
Report-To: { "group": "endpoint-1",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/reports" },
               { "url": "https://backup.com/reports" }
             ] }

Content-Security-Policy: ...; report-to endpoint-1
```

브라우저 호환성

이 페이지의 호환성 테이블은 구조화된 데이터에서 생성됩니다. 데이터에 기여하고 싶다면 https://github.com/mdn/browser-compat-data 를 확인하고 pull request를 보내주세요.

See also
--------

* `Content-Security-Policy` (en-US)
* `Content-Security-Policy-Report-Only` (en-US)


CSP: default-src - HTTP

CSP: default-src
================

HTTP `Content-Security-Policy` (en-US) (CSP) **`default-src`** 구문은 다른 CSP 구문이 정의되지 않았을때 이를 대체하는 용도로 사용됩니다. as a fallback for the other CSP fetch directives. 다음과 같은 구문이 없는 경우, `default-src` 구문을 찾아서 사용합니다:

* `child-src` (en-US)
* `connect-src` (en-US)
* `font-src` (en-US)
* `frame-src` (en-US)
* `img-src`
* `manifest-src` (en-US)
* `media-src` (en-US)
* `object-src` (en-US)
* `script-src`
* `style-src` (en-US)
* `worker-src`

| CSP version | 1 |
| --- | --- |
| Directive type | Fetch directive |

Syntax
------

하나 이상의 출처가 `default-src` 정책에 의해서 허용될 수 있습니다:
```

Content-Security-Policy: default-src <source>;
Content-Security-Policy: default-src <source> <source>;
```

### Sources

<source> 에는 다음에 항목이 포함됩니다.

<host-source>

 부수적으로 URL scheme 및/또는 port 번호가 포함된 도메인 또는 IP 주소와 같은 인터넷 호스트, 또한 사이트의 주소 및 포트에 와일트 카드를 사용할 수 도 있습니다 (`'*'`), 이를 사용하면 모든 주소 또는 포트에서의 유효함을 나타냅니다.
 예:

* `http://*.example.com`: `http:` 를 사용하는 모든 서브도메인에서 매칭됩
* `mail.example.com:443`: 443 포트로 mail.example.com에 접근하는 경우 매칭됨
* `https://store.example.com`: store.example.com를 `https:`로 접근하는 경우 매칭됨

<scheme-source>

'http:' 또는 'https:'와 같은 스키마. **콜론이 필수적이며, 작은 따음표는 사용하지 않아야 합니다.** 스키마도 지정할 수 있습니다 (추천하지 않음).

* `data:``data:` URIs 를 컨텐츠 출처로 허용합니다. 이것은 안전하지 않습니다. *공격자가 임의의 데이터를 주입할 수도 있기 때문에 script에는 사용하지 마십시오.*
* `mediastream:``mediastream:` URIs (en-US) 을 콘텐츠 출처로 허용합니다.
* `blob:``blob:` URIs을 콘텐츠 출처로 허용합니다.
* `filesystem:``filesystem:` URIs (en-US) 을 콘텐츠 출처로 허용합니다.

`'self'`

동일한 URL 체계와 포트를 포함하여 보호되는 파일의 원본을 참조합니다. 작은 따음표가 필수적으로 있어야 합니다. 일부 브라우저에서는 `blob` 와 `filesystem` 를 source 지시문에서 제외합니다. 이러한 콘텐츠 타입을 허용해야 하는 사이트는 데이터 attribute를 사용하여 지정할 수 있습니다.

`'unsafe-inline'`

인라인 `<script>` 태그, `javascript:` URLs, 인라인 이벤트 핸들러, 그리고 인라인 `<style>` 태그와 같은 인라인 요소들을 모두 허용합니다. 작은 따음표를 사용해야만 합니다.

`'unsafe-eval'`

`eval()` 및 문자열에서 코드를 생성하는 함수의 사용을 허용합니다. 작은 따음표를 사용해야만 합니다.

`'none'`

아무것도 참조 되지 않습니다. 즉 아무런 URL도 매치되지 않습니다. 작은 따음표를 사용해야만 합니다.

'nonce-<base64-value>'

암호화 nonce 값을 이용하여 특정 인라인 스크립트에 대하여 허용합니다(nonce는 한번만 사용). 서버는 CSP정책을 전송할 때마다 고유한 nonce를 생성해야만 합니다. 리소스 정책을 우회하는 것은 간단한 일이기 때문에 의심 할 여지가 없는 nonce 값을 제공하는 것이 중요합니다. unsafe inline script 예제를 참고해주세요. nonce는 `'unsafe-inline'` 와 함께 사용할 경우 모던 브라우저에서는 사용하게 되면 `'unsafe-inline'`가 무시되지만, 구형 브라우저에서는 nonce가 적용되지 않습니다.

'<hash-algorithm>-<base64-value>'

스크립트 또는 스타일의 sha256, sha384 or sha512 해쉬. 이것은 대쉬: 로 구분된 해쉬를 사용된 암호화 알고리즘과 base64로 인코딩한 스크립트 및 스타일로 구성됩니다. 해쉬를 생성할 때 절대로 <script> 또는 <style> 태그를 포함하지말고 대소문자와 앞 뒤의 공백을 주의해야 합니다.unsafe inline script 예제를 참고해주세요. CSP 2.0에서는 인라인 스크립트에서만 적용 가능하지만, CSP 3.0에서는 외부 스크립트를 `script-src` 에서 허용하기 위해서 사용합니다.

'strict-dynamic'

The `strict-dynamic` source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any whitelist or source expressions such as `'self'` or `'unsafe-inline'` will be ignored. See script-src for an example.

Examples
--------

### `default-src`의 상속 불가

다른 구문이 지정되면 default-src는 더 이상 영향을 주지 않습니다. 아래의 헤더는
```

Content-Security-Policy: default-src 'self'; script-src https://example.com
```

다음과 같습니다:
```

Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src https://example.com;
                         style-src 'self';
                         worker-src 'self'
```

명세서
---

| Specification |
| --- |
| Content Security Policy Level 3 # directive-default-src |

Browser compatibility
---------------------

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

See also
--------

* `Content-Security-Policy` (en-US)
* `connect-src` (en-US)
* `font-src` (en-US)
* `frame-src` (en-US)
* `img-src`
* `manifest-src` (en-US)
* `media-src` (en-US)
* `object-src` (en-US)
* `script-src`
* `style-src` (en-US)
* `worker-src`


CSP: worker-src - HTTP

CSP: worker-src
===============

HTTP `Content-Security-Policy` (en-US) (CSP) **`worker-src`** 지시문은 `Worker`, `SharedWorker`, 또는 `ServiceWorker`의 유효한 스크립트 소스를 지정합니다.

|  |  |
| --- | --- |
| CSP 버전 | 3 |
| 지시 형식 | Fetch directive |
| 대비책 | 이 지시문이 없으면 사용자 에이전트는 먼저 `child-src` (en-US) 지시문을 찾은 다음 `script-src` 지시문을 찾고, 마지막으로 `default-src` 지시문을 찾습니다. |

구문
--

`worker-src` 정책에 대해 하나 이상의 소스를 허용할 수 있습니다.

```http
Content-Security-Policy: worker-src <source>;
Content-Security-Policy: worker-src <source> <source>;
```

### 소스

`<source>`는 CSP Source Values (en-US)에 나열된 값 중 하나입니다.

이 값은 모든 fetch 지시문 및 기타 여러 지시문 (en-US)에서 사용할 수 있습니다.

예제
--

### 위반 사례

주어진 CSP 해더가 다음과 같다면

```http
Content-Security-Policy: worker-src https://example.com/
```

아래에서 `Worker`, `SharedWorker`, `ServiceWorker`는 차단되어 로드되지 않습니다.

```html
<script>
 let blockedWorker = new Worker("data:application/javascript,…");
 blockedWorker = new SharedWorker("https://not-example.com/");
 navigator.serviceWorker.register("https://not-example.com/sw.js");
</script>
```

명세서
---

| Specification |
| --- |
| Content Security Policy Level 3 # directive-worker-src |

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

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

같이 보기
-----

* `Content-Security-Policy` (en-US)
* 웹 워커를 위한 CSP (en-US)
* `Worker`, `SharedWorker`, `ServiceWorker`


CSP: img-src - HTTP

CSP: img-src
============

The HTTP `Content-Security-Policy` (en-US)`:` **`img-src`** 지시어는 이미지 및 파비콘에 대하여 유효한 출처를 지정합니다.

|  |  |
| --- | --- |
| CSP version | 1 |
| Directive type | Fetch directive |
| `default-src` fallback |
 Yes. If this directive is absent, the user agent will look for the
 `default-src` directive.
  |

Syntax
------

`img-src` 정책에 대해 하나 이상의 출처를 허용 할 수 있습니다.
```

Content-Security-Policy: img-src <source>;
Content-Security-Policy: img-src <source> <source>;
```

### Sources

`<source>` can be any one of the values listed in CSP Source Values (en-US).

Note that this same set of values can be used in all fetch directives (and a number of other directives (en-US)).

Examples
--------

### Violation cases

CSP 헤더가 주어질 때:

```bash
Content-Security-Policy: img-src https://example.com/
```

아래의 `<img>` 태그가 차단되어 불러오지 않습니다:

```html
<img src="https://not-example.com/foo.jpg" alt="example picture" />
```

명세서
---

| Specification |
| --- |
| Content Security Policy Level 3 # directive-img-src |

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

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

See also
--------

* `Content-Security-Policy` (en-US)
* `<img>`


www와 비-www URL 중에서 선택하기 - HTTP

www와 비-www URL 중에서 선택하기
=======================

웹 사이트 소유자들이 반복해서 하게 되는 질문은 비-www 혹은 www URL 중 무엇을 선택해야 하는가입니다. 이 페이지는 그에 대해 최선의 결론을 내기 위한 조언을 제공합니다.

도메인 네임이란 무엇인가요?
---------------

HTTP URL에서, 앞 부분의 `http://` 또는 `https://` 다음에 오는 첫번째 하위 문자열을 도메인 네임이라 부릅니다. 도메인 네임은 문서가 위치하고 있는 서버에서 호스팅됩니다.

서버는 꼭 물리적인 하드웨어일 필요는 없습니다. 몇몇 서버들은 같은 물리적 하드웨어 위에 함께 위치할 수 있습니다. 혹은, 한 개의 서버가 여러 하드웨어들에 의해 처리되어, 결과를 만들어내는데 동조하거나 그들 사이에서 요청에 대한 부하를 균형있게 조정할 수도 있습니다. 요점은 의미적으로 '하나의 도메인 이름이 하나의 단일 서버를 나타낸다'는 것입니다.

그래서, 내 사이트 웹에 대해 하나 또는 다른 것을 선택해야만 하나요?
---------------------------------------

* **그렇습니다**, 하나를 선택하고 그것과 함께 결속될 필요가 있습니다. 당신의 표준 위치로 할 것을 선택하는 것은 당신의 몫이며, 한 가지를 선택하는 경우 그것과 결속되게 됩니다. 그것은 당신의 웹 사이트를 당신의 사용자 그리고 검색 엔진에게 있어 좀 더 일관되게 보이도록 만들어줄 것입니다. 이것은 선택된 도메인에 대해 항상 링크되는 것(당신의 웹 사이트에서 상대 URL을 사용하고 있는 경우 어렵지 않아야 함)과 동일한 도메인에 대한 링크를 (이메일이나 소셜 네트워크 등에 의해) 항상 공유하는 것을 포함합니다.
* **그렇지 않습니다**, 두 가지 모두를 가질 수는 없습니다. 중요한 것은 당신이 공식 도메인을 이용해 결속되어 있고 일관되다는 것입니다. **이 공식 도메인을 '표준' 이름이라고 부릅니다.** 당신의 모든 절대 링크는 그 이름을 사용해야 합니다. 그러나 그럼에도, 당신은 여전히 동작하는 다른 도메인을 가질 수 있습니다. HTTP는 두 가지 기술을 허용하므로 비표준 도메인이 동작하고 예상되는 페이지를 제공하도록 허용되고 있는 동안에도 도메인이 표준 도메인인 당신의 사용자 혹은 검색 엔진에게 있어서 명확할 것입니다.

그러므로, 당신의 도메인 중 하나를 당신의 표준 도메인으로 선택하세요! 표준 도메인이 아닌 도메인을 여전히 동작하도록 만들기 위한 두 가지 기술을 아래에 소개합니다.

표준 URL을 위한 기술들
--------------

'표준' 웹 사이트를 선택하기 위한 서로 다른 방법들이 있습니다.

### HTTP 301 리다이렉트 사용하기

이 경우에, 비표준 도메인에 대한 알맞은 HTTP `301`로 응답하기 위해 서버가 (www 그리고 비(非)-www URL에 대해 거의 동일해보이는) HTTP 요청을 받도록 구성해야 할 필요가 있습니다. 이것은 표준 URL과 동등한 비표준 URL에 접근하도록 브라우저를 리다이렉트시킬 겁니다. 예를 들어, 비-www URLs을 표준 타입으로 사용하도록 선택했다면, 모든 www URL들은 그와 동등한 www가 없는 URL로 리다이렉트되게 됩니다.

예제입니다.

1. 서버가 `http://www.example.org/whaddup` 에 대한 요청을 받습니다(표준 도메인이 example.org인 경우).
2. 서버는 헤더인 `Location` (en-US): `http://example.org/whaddup` 와 함께 `301` 코드로 응답하게 됩니다.
3. 클라이언트는 표준 도메인 `http://example.org/whatddup`에 대한 요청을 발급합니다.

HTML5 보일러플레이트 프로젝트는 하나의 도메인을 다른 도메인으로 리다이렉트 시키도록 Apache 서버 구성하는 방법에 대한 예제를 가지고 있습니다.

### <link rel="canonical"> 사용하기

페이지의 표준 주소가 무엇인지를 가리키기 위해 페이지에 특별한 HTML `<link>` 요소를 추가하는 것이 가능합니다. 이것은 페이지를 보는 사람에게는 별 다른 영향이 없지만 검색 엔진 크롤러에게 페이지가 실제로 위치한 곳을 알려줍니다. 그렇게 하면 검색 엔진이 동일한 페이지를 여러 번 색인하지 않으므로, 중복 컨텐츠 혹은 어떤 종류의 스팸으로 간주하게 될 수도 있고 심지어 검색 엔진 결과 페이지에서 당신의 페이지를 제거하거나 우선순위가 낮아질 수도 있습니다.

그런 태그를 추가하게 되면, 두 가지 도메인에 대해 같은 내용을 서브하며 어떤 URL이 표준인지를 검색 엔진에게 알려주게 됩니다. 이전 예제에서, `http://www.example.org/whaddup` 는 `http://example.org/whaddup`와 동일한 내용을 서브하지만 head 태그 내 추가적인 `<link>` 요소가 자리하고 있을 겁니다:

```html
<link href="http://example.org/whaddup" rel="canonical" />
```

이전 경우와 다르게, 브라우저 기록은 비-www와 www URL을 개별적인 엔트리로 판단할 겁니다.

페이지가 두 가지 경우 모두에 동작하도록 만드세요
---------------------------

앞서 말한 기술들을 가지고, 서버가 www와 접두화된 도메인과 그렇지 않은 도메인 모두에 정확하게 응답하도록 구성할 수 있습니다. 이것은 브라우저의 URL 표시줄에 사용자가 어떤 URL을 입력할지 예상할 수가 없기에 좋은 조언입니다. 정식 위치로 사용할 타입을 선택한 다음 다른 타입으로 리다이렉션하는 것이 중요합니다.

결정하기
----

이것은 자전거 타기(bikeshedding) 이슈로 간주될 수도 있는 주관적인 주제입니다. 더 자세한 정보를 얻으려면, 이 주제에 관련된 글들을 읽어보세요.

* 2020년 'www.netlify.com'의 bare 도메인에 대한 옵션
* 2023년 'www.wpbeginner.com'의 www vs 비-www WordPress SEO에 더 나은 것은 무엇인가요?
같이 보기
-----

* 2011년 URL 주소창에서 사람들이 입력하는 것들의 현황


MIME 타입 (IANA 미디어 타입) - HTTP

MIME 타입 (IANA 미디어 타입)
=====================

**미디어 타입** (**Multipurpose Internet Mail Extensions 또는 MIME type**로도 알려져 있음)이란 문서, 파일 또는 바이트 집합의 성격과 형식을 나타냅니다. MIME 타입은 IETF의 RFC 6838에 정의 및 표준화되어 있습니다.

인터넷 할당 번호 관리 기관(IANA)은 모든 공식 MIME 타입을 담당하며 미디어 타입에서 가장 최신의 전체 목록을 찾을 수 있습니다.

**경고:** 브라우저는 '파일 확장자가 아닌' MIME 타입을 사용하여 URL 처리 방법을 결정합니다.
 따라서, 웹 서버가 응답의 `Content-Type` 헤더에 올바른 MIME 타입을 보내는 것이 중요합니다.
 올바르게 구성하지 않으면, 브라우저가 파일 내용을 잘못 해석할 가능성이 높고, 사이트가 제대로 작동하지 않고 다운로드한 파일이 잘못 처리될 수 있습니다.

MIME 타입의 구조
-----------

MIME 타입은 가장 일반적으로 슬래시(`/`)로 구분된 'type'과 'subtype'의 두 부분으로 구성됩니다. 또한 이 사이에는 공백이 없습니다.
```

type/subtype
```

***type***은 `video` 또는 `text`와 같이 데이터 타입이 속하는 일반 카테고리를 나타냅니다.

***subtype***은 MIME 타입이 나타내는 지정된 타입의 정확한 데이터 종류를 식별합니다.
 예를 들어, MIME 타입 `text`의 경우 하위 타입은 `plain` (평문 텍스트), `html` (HTML 소스 코드) 또는 `calendar` (iCalendar/`.ics` 용)입니다.

각 타입에는 고유한 하위 타입이 있습니다. MIME 타입은 항상 타입과 하위 타입 모두 가지며, 둘 중 하나만 가지지는 않습니다.

추가적인 세부정보를 제공하기 위해 선택적 **매개변수**를 추가할 수 있습니다.
```

type/subtype;parameter=value
```

 예를 들어, 기본 타입이 `text`인 MIME 타입의 경우 선택적 `charset` 매개변수를 추가하여 데이터의 문자에 사용되는 문자 세트를 지정할 수 있습니다.
 `문자 집합`이 지정되지 않은 경우, 사용자 에이전트 설정으로 재정의되지 않는 한 기본 값은 ASCII (`US-ASCII`)입니다.
 UTF-8 텍스트 파일을 지정하려면, MIME 타입 `text/plain;charset=UTF-8`이 사용됩니다.

MIME 타입은 대소문자를 구분하지는 않지만 전통적으로 소문자로 쓰여집니다. 매개변수 값은 대소문자를 구분할 수 있습니다.

### 타입

 타입에는 **discrete** 및 **multipart**라는 두 가지 클래스가 있습니다. 개별 타입은 단일 텍스트나 음악 파일, 단일 비디오 등 단일 파일이나 매체를 나타내는 타입입니다.
 multipart 타입은 여러 컴포넌트 조각으로 구성된 문서를 나타내며, 각 부분은 고유한 개별 MIME 타입을 가질 수 있고, multipart 타입은 하나의 트랜잭션으로 함께 전송되는 여러 파일을 캡슐화할 수 있습니다.
 예를 들어, 이메일에 여러 파일을 첨부할 때 multipart MIME 타입이 사용됩니다.

### 개별 타입

현재 IANA에 등록된 개별 타입은 다음과 같습니다.

`application`

 다른 타입 중 하나에 명시적으로 속하지 않는, 모든 종류의 이진 데이터입니다.
 어떤 방식으로든 실행되거나 해석될 데이터 또는 특정 어플리케이션이나 어플리케이션 범위를 사용해야 하는 이진 데이터 입니다.
 일반 이진 데이터(또는 실제 타입을 알 수 없는 이진 데이터)는 `application/octet-stream`입니다.
 다른 일반적인 예로는 `application/pdf`, `application/pkcs8` 및 `application/zip`을 들 수 있습니다.
 (IANA에서 애플리케이션 타입 레지스트리를 확인하세요)

`audio`

 오디오 또는 음악 데이터입니다. 예로는 `audio/mpeg`,
 `audio/vorbis`를 들 수 있습니다.
 (IANA에서 오디오 타입 레지스트리를 확인하세요)

`example`

 MIME 타입을 사용하는 방법을 보여주는 예제에서, 자리 표시자로 사용하도록 예약되어 있습니다. 이 타입은 샘플 코드 목록 및 문서 외부에서 사용되어선 안 됩니다.
 `example`은 하위 타입으로도 사용될 수 있습니다.
 예를 들어, 웹에서 오디오 작업과 관련된 경우, MIME 타입 `audio/example`은 해당 타입이 자리 표시자임을 나타내기 위해 사용될 수 있고, 실제 코드를 사용할 때 적절한 타입으로 대체되어야 합니다.

`font`

 글꼴/서체 데이터입니다. 일반적인 예로 `font/woff`, `font/ttf` 및 `font/otf`를 들 수 있습니다.
 (IANA에서 글꼴 타입 레지스트리를 확인하세요)

`image`

 비트맵과 벡터 정지 이미지를 모두 포함하는 이미지 또는 그래픽 데이터 애니메이션 GIF 또는 APNG와 같은 정지 이미지 형식의 애니메이션 버전입니다.
 일반적인 예로`image/jpeg`, `image/png` 및 `image/svg+xml`를 들 수 있습니다.
 (IANA에서 이미지 타입 레지스트리를 확인하세요)

`model`

 3D 객체 또는 화면에 대한 모델 데이터입니다. 일반적인 예로 `model/3mf` 및 `model/vrml`를 들 수 있습니다..
 (IANA에서 모델 타입 레지스트리를 확인하세요)

`text`

 사람이 읽을 수 있는 콘텐츠, 소스 코드 또는 쉼표로 구분된 값 (CSV) 형태 데이터와 같은, 텍스트 형식의 데이터를 가지는 텍스트 전용 데이터입니다.
 예로는 `text/plain`, `text/csv` 및 `text/html`이 있습니다.
 (IANA에서 텍스트 타입 레지스트리를 확인하세요)

`video`

 MP4 영화(`video/mp4`)와 같은 비디오 데이터 또는 파일입니다.
 (IANA에서 비디오 타입 레지스트리를 확인하세요)

 특정 하위 타입이 없는 텍스트 문서의 경우, `text/plain`을 사용해야 합니다.
 마찬가지로, 특정 하위 타입이나 알려진 하위 타입이 없는 이진 데이터로 이루어진 문서의 경우, `application/octet-stream`을 사용해야 합니다.

### Multipart 타입

**Multipart** 타입은 일반적으로 다른 MIME 타입들을 지닌 개별적인 파트들로 나누어지는 문서의 그룹을 나타냅니다. 종종 MIME 타입이 다른 부분은 특히 이메일 시나리오(모두 동일한 파일의 일부이며 여러 개의 각각의 파일을 나타냄(**복합 문서**를 의미))에서도 사용할 수 있습니다.

HTML Forms 의 `POST` 메서드에서 사용되는 `multipart/form-data`와 문서 일부분을 보내기 위해 `206` `Partial Content`를 사용하는 `multipart/byteranges`를 제외하면, HTTP는 다중부분 문서를 특별한 방식으로 처리하지 않습니다. 메시지가 브라우저로 전송됩니다(아마도 문서를 표시하는 방법을 모르는 경우 '다른 이름으로 저장'창을 표시함).

2개의 다중부분 타입이 있습니다.

`message`

 다른 메시지를 캡슐화하는 메시지입니다. 예를 들어, 데이터의 일부로 전달된 메시지가 포함되어 있는 이메일을 나타내는 데 사용할 수 있거나 또는 마치 여러 메시지인 것럼 매우 큰 메시지를 청크로 나누어 보낼 수 있습니다. 예를 들어, 데이터의 일부로 전달된 메시지가 포함된 이메일을 나타내는 데 사용할 수 있습니다. 또는 마치 여러 메시지인 것처럼 매우 큰 메시지를 청크로 나누어 보낼 수 있습니다.
 예를 들면, `message/rfc822` (전달되거나 회신된 메시지 인용) 및 `message/partial`을 포함하여 큰 메시지를 자동으로 작은 메시지로 나누어 수신자가 재조립할 수 있도록 합니다.
 (IANA에서 메시지 타입 레지스트리를 확인하세요)

`multipart`

 개별적으로 서로 다른 MIME 타입을 가질 수 있는 여러 컴포넌트로 구성된 데이터입니다.
 예를 들어 `multipart/form-data` (`FormData` API를 사용해 생성된 데이터의 경우) 및 `multipart/byteranges` (defined in RFC 7233, 섹션 5.4.1에 정의되어 있고 HTTP의 `206` "Partial Content"와 함께 사용됩니다. 가져온 데이터는 `Range` 헤더를 사용하여 전달되는 것과 같이 콘텐츠의 일부일 뿐입니다).
 (IANA에서 Multipart 타입 레지스트리를 참조하세요)

웹 개발자들을 위한 중요한 MIME 타입
----------------------

### `application/octet-stream`

이 타입은 이진 파일을 위한 기본값입니다. 이 타입은 실제로 '잘 알려지지 않은' 이진 파일을 의미하므로, 브라우저는 보통 자동으로 실행하지 않거나 실행해야 할지 묻기도 합니다. `Content-Disposition` 헤더가 값 `attachment` 와 함게 설정되었고 'Save As' 파일을 제안하는지 여부에 따라 브라우저가 그것을 다루게 됩니다.

### `text/plain`

이것은 텍스트 파일에 대한 기본값입니다. 실제로 '알려지지 않은 텍스트' 파일일지라도 브라우저들은 그것을 보여줄 수 있다고 가정합니다.

**참고:** `text/plain`이 '모든 종류의 텍스트 데이터'를 의미하지는 않습니다.
 만약 브라우저가 특정 종류의 텍스트 데이터를 예상한 경우, 반드시 일치한다고 간주하지 않을 겁니다.
 특히, CSS 파일을 선언한 `<link>` 요소로부터 `text/plain` 파일을 다운로드할 경우, `text/plain`으로 표현된다면 브라우저는 그것을 유효한 CSS 파일로 감지하지 않을 겁니다.
 CSS의 MIME 타입인 `text/css`이 사용되어야만 합니다.

### `text/css`

 웹 페이지를 그리는 CSS 파일들은 `text/css` 파일이 **되어야만 합니다**.
 서버가 `.css` 접미사를 가진 파일들을 CSS 파일이라고 인식하지 못하면, `text/plain` 또는 `application/octet-stream` MIME 타입으로 전송할지도 모릅니다.
 이런 경우 대부분의 브라우저들이 CSS 파일이라고 인식하지 못하며 조용히 무시될 겁니다.

### `text/html`

모든 HTML 컨텐츠는 이 타입과 함께 제공되어야 합니다. `application/xml+html`와 같은 XHTML을 위한 대체 MIME 타입들은 현재에는 대부분 사용되지 않습니다.

### `text/javascript`

IANA 미디어 타입마다, RFC 9239 및 HTML 명세, JavaScript 컨텐츠는 MIME 타입 `text/javascript` 사용해서 제공되어야 합니다.
 다른 MIME 타입은 JavaScript에 유효한 것으로 간주되지 않으며, `text/javascript` 이외의 MIME 타입을 사용하면 스크립트가 로드되거나 실행되지 않을 수 있습니다.

 일부 JavaScript 콘텐츠는 스크립트 콘텐츠에 대한 문자 집합을 지정하려는 시도로, MIME 타입의 일부로 `charset` 매개변수와 함께 잘못 제공되는 것을 발견할 수 있습니다.
 해당 `charset` 매개변수는 JavaScript 콘텐츠에 유효하지 않으며, 대부분의 경우 스크립트 로드에 실패하게 됩니다.

#### 레거시 JavaScript MIME 타입

역사적 이유로 `text/javascript` MIME 타입 외에도 MIME 스니핑 표준 (브라우저가 MIME 타입을 해석하고 유효한 타입이 없는 콘텐츠로 무엇을 해야 하는지 파악하는 방법에 대한 정의)을 사용하면 다음 레거시 JavaScript MIME 타입을 사용하여 JavaScript를 제공할 수도 있습니다.

* `application/javascript`
지원이 중단되었습니다
* `application/ecmascript`
지원이 중단되었습니다
* `application/x-ecmascript`
비표준
* `application/x-javascript`
비표준
* `text/ecmascript`
지원이 중단되었습니다
* `text/javascript1.0`
비표준
* `text/javascript1.1`
비표준
* `text/javascript1.2`
비표준
* `text/javascript1.3`
비표준
* `text/javascript1.4`
비표준
* `text/javascript1.5`
비표준
* `text/jscript`
비표준
* `text/livescript`
비표준
* `text/x-ecmascript`
비표준
* `text/x-javascript`
비표준

**참고:** 주어진 사용자 에이전트가 이들 중 일부 또는 전부를 지원할 수 있더라도 `text/javascript`만 사용해야 합니다.
 현재는 물론 앞으로도 작동이 보장되는 유일한 MIME 타입입니다.

### 이미지 타입

MIME 타입이 `image`인 파일에는 이미지 데이터가 포함되어 있습니다. 하위 타입은 데이터가 나타내는 특정 이미지 파일 형식을 지정합니다.

다음 이미지 타입은 웹페이지에서 사용하기에 '안전한' 것으로 간주될 만큼 일반적으로 사용됩니다.

* `image/apng` (en-US): Animated Portable Network Graphics (APNG)
* `image/avif` (en-US) : AV1 이미지 파일 포맷 (AVIF)
* `image/gif` (en-US): Graphics Interchange 포맷 (GIF)
* `image/jpeg` (en-US): Joint Photographic Expert Group 이미지 (JPEG)
* `image/png` (en-US): Portable Network Graphics (PNG)
* `image/svg+xml` (en-US): Scalable Vector Graphics (SVG)
* `image/webp` (en-US): Web Picture 포맷 (WEBP)

이미지 파일 타입 및 포맷 가이드 (en-US)에서는 다양한 이미지 포맷을 사용해야 하는 경우에 대한 정보와 권장사항을 제공합니다.

### 오디오와 비디오 타입

이미지 경우처럼, HTML은 `<audio>` (en-US)과 `<video>` 요소에 사용하기 위한 특정 파일 및 코덱 타입을 지원하도록 요구하지 않으므로 중요합니다. 미디어에 사용할 파일 형식과 코덱을 선택할 때 대상 고객과 사용할 수 있는 브라우저 범위(및 해당 브라우저의 버전)를 고려하세요.

미디어 컨테이너 형식 가이드는 웹 브라우저에서 일반적으로 지원되는 파일 형식 목록을 제공합니다. 특별한 사용 사례에 대한 정보, 단점, 호환성 정보 및 기타 세부 정보가 포함되어 있습니다.

오디오 코덱 (en-US) 및 비디오 코덱 가이드에는 웹 브라우저가 지원하는 다양한 코덱이 나열되어 있습니다. 지원하는 오디오 채널 수, 사용되는 압축의 종류, 유용한 비트 전송률 등과 같은 기술 정보와 함께 호환성 세부 정보를 제공하는 경우가 많습니다.

WebRTC에서 사용하는 코덱 (en-US) 안내서는 주요 웹 브라우저에서 지원하는 코덱을 구체적으로 다루면서, 확장하므로 지원하는 브라우저 범위에 가장 적합한 코덱을 선택할 수 있습니다.

오디오 또는 비디오 파일의 MIME 타입은 일반적으로 컨테이너 형식(파일 타입)을 지정합니다. 선택적 코덱 매개변수를 MIME 타입에 추가하여 사용할 코덱과 미디어 인코딩에 사용됩 옵션(예, 코덱 프로필, 레벨, 기타 정보)을 추가로 지정할 수 있습니다.

웹 콘텐츠에 사용되는 가장 일반적인 MIME 유형은 다음과 같지만, 사용 가능한 모든 유형의 전체 목록은 아닙니다. 자세한 내용은 미디어 컨테이너 형식 가이드를 참조하세요.

| MIME 타입 | 오디오 및 비디오 타입 |
| --- | --- |
| `audio/wave`, `audio/wav`, `audio/x-wav`, `audio/x-pn-wav` | WAVE 컨테이너 형식의 오디오 파일입니다. PCM 오디오 코덱 (WAVE 코덱 "1")은 종종 지원되지만, 다른 코덱은 지원이 제한됩니다. |
| `audio/webm` | WebM 컨테이너 형식의 오디오 파일입니다. Vorbis 및 Opus는 WebM 명세에서 공식적으로 지원하는 코덱입니다. |
| `video/webm` | WebM 컨테이너 형식의 비디오 파일(오디오 포함 가능) VP8 및 VP9는 가장 일반적인 비디오 코덱입니다. Vorbis 및 Opus는 가장 일반적인 오디오 코덱입니다. |
| `audio/ogg` | Ogg 컨테이너 형식의 오디오 파일입니다. Vorbis는 이러한 컨테이너에 사용되는 가장 일반적인 코덱이지만, Opus는 이제 Ogg에서도 지원됩니다. |
| `video/ogg` | Ogg 컨테이너 형식의 비디오 파일(오디오 포함 가능) Theora는 그 안에서 사용되는 일반적인 비디오 코덱입니다. Vorbis가 일반적으로 오디오 코덱이지만, Opus가 점점 더 보편화되고 있습니다. |
| `application/ogg` | Ogg 컨테이너 형식을 사용하는 오디오 또는 비디오 파일입니다. Theora는 그 안엗서 사용되는 일반적인 비디오 코덱입니다. Vorb is는 일반적인 오디오 코덱입니다. |

### `multipart/form-data`

`multipart/form-data`은 브라우저에서 서버로 완성된 HTML Form (en-US)의 내용을 전송 시 사용할 수 있습니다.

다중부분 문서 형식으로써, 경계(이중 대시 `'--'` 로 시작되는 문자열)로 구분되어지는 다른 파트들로 구성됩니다. 각 파트는 그 자체로 개체이며 자신만의 HTTP 헤더를 가지는데, 파일 업로드 필드를 위한 헤더로는 `Content-Disposition`, `Content-Type`이 있습니다.

```http
Content-Type: multipart/form-data; boundary=aBoundaryString
(other headers associated with the multipart document as a whole)

--aBoundaryString
Content-Disposition: form-data; name="myFile"; filename="img.jpg"
Content-Type: image/jpeg

(data)
--aBoundaryString
Content-Disposition: form-data; name="myField"

(data)
--aBoundaryString
(more subparts)
--aBoundaryString--
```

다음은 HTML `<form>`입니다:

```html
<form
 action="http://localhost:8000/"
 method="post"
 enctype="multipart/form-data">
  <label>Name: <input name="myTextField" value="Test" /></label>
  <label><input type="checkbox" name="myCheckBox" /> Check</label>
  <label>
    Upload file: <input type="file" name="myFile" value="test.txt" />
  </label>
  <button>Send the file</button>
</form>
```

`<form>`은 다음 메시지를 전송하게 됩니다:

```http
POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myTextField"

Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--
```

### `multipart/byteranges`

`multipart/byteranges` MIME 타입은 브라우저에 부분적 응답을 보내는 데 사용됩니다.

`206 Partial Content` 상태 코드가 전송된 경우, MIME 타입은 문서가 각각의 요청된 범위들 중 하나인 몇 가지 파트들로 구성되어 있음을 알려주기 위해 사용됩니다. 다른 다중부분 타입처럼, `Content-Type`은 이 조각들을 분리하기 위해 `boundary` 디렉티브를 사용합니다. 각각의 다른 파트들은 문서의 실제 타입을 가진 `Content-Type` 헤더와 그들이 나타내는 범위를 가진 `Content-Range`를 지니고 있습니다.

```http
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
 <meta name="viewport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
 margin: 0;
 padding: 0;
 font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
```

정확한 MIME 타입 설정의 중요성
-------------------

대부분의 웹 서버들은 기본 타입 중 하나인 `application/octet-stream` MIME 타입을 사용해 알려지지 않은 타입의 리소스를 전송합니다. 보안상의 이유로, 대부분의 브라우저들은 그런 리소스에 대한 사용자 정의된 기본 동작 설정을 허용하지 않으며, 그것을 사용하려면 디스크에 저장해야 합니다.

자주 발생하는 잘못된 서버 구성입니다.

* RAR로 인코딩된 파일.
 이 경우에, 이상적인 부분은 원본 파일의 실제 타입입니다. .RAR 파일은 다양한 타입의 여러 리소스를 보유할 수 있으므로 이는 종종 불가능합니다.
 이 경우는, `application/x-rar-compressed`를 전송하도록 서버를 구성하세요.
* 오디오 및 비디오.
 올바른 MIME 타입을 가진 리소스만 `<video>` 또는 `<audio>` (en-US) 요소에서 재생됩니다.
 오디오 및 비디오 미디어 타입 (en-US)을 반드시 정확하게 지정하세요.
* 독점 파일 형식.
 대부분의 브라우저는 이 일반 MIME 타입에 대한 기본 동작(예, "Word에서 열기") 정의를 허용하지 않으므로 `application/octet-stream`을 사용하지 마세요.
 `application/vnd.mspowerpoint`와 같은 특정 타입을 사용하면 사용자가 선택한 프레젠테이션 소프트웨어에서 이러한 파일을 자동으로 열 수 있습니다.
MIME 스니핑
--------

MIME 타입이 없거나 브라우저가 MIME 타입이 올바르지 않다고 판단하는 경우, 브라우저는 리소스의 바이트를 보고 올바른 MIME 타입을 추측하는 'MIME 스니핑'을 수행할 수 있습니다.

각 브라우저는 서로 다른 상황에서 MIME 스니핑을 다르게 수행합니다. (예를 들어, Safari는 전송된 MIME 타입이 적합하지 않은 경우 URL 파일 확장자를 확인합니다) 일부 MIME 타입은 실행 가능한 콘텐츠를 나타내므로 보안 문제가 있습니다. 서버는 `X-Content-Type-Options` (en-US) 헤더를 전송하여 MIME 스니핑을 방지할 수 있습니다.

문서 타입을 전달하는 다른 방법
-----------------

MIME 타입이 문서 타입 정보를 전달하는 유일한 방법은 아닙니다.

* 특히 Microsoft Windows에서는 파일 이름 접미사가 사용되는 경우가 있습니다.
 모든 운영 체제에서 이러한 접미사를 의미 있는 것으로 간주하는 것은 아니며(예, Linux 및 macOS), 접미사가 정확하다는 보장도 없습니다.
* 매직 넘버. 다양한 형식의 구문을 사용하면 바이트 구조를 보고 파일 타입을 추론할 수 있습니다.
 예를 들어, GIF 파일은 16진수 `47 49 46 38 39` (`GIF89`)로 시작하고, PNG 파일은 `89 50 4E 47` (`.PNG`)로 시작합니다.
 모든 파일 형식에 매직 넘버가 있는 것은 아니므로, 이 역시 100% 신뢰할 수는 없습니다.
같이 보기
-----

* 웹 미디어 기술
* 웹에서 사용되는 미디어 타입 가이드 (en-US)
* 서버의 MIME 타입을 적절하게 구성하기 (en-US)


데이터 URI - HTTP

데이터 URI
=======

**데이터 URL**, `data:` 스킴이 접두어로 붙은 URL은 컨텐츠 작성자가 작은 파일을 문서 내에 인라인으로 삽입할 수 있도록 해줍니다. WHATWG에 의해 해당 이름이 없어질 때까지 이전에는 "데이터 URI"로 알려졌습니다.

**참고:** 데이터 URL은 탐색을 담당하는 설정 객체의 출처를 상속받지 않고 최신 브라우저에서 고유하고 불투명한 출처로 처리됩니다.

구문
--

데이터 URI는 접두사(`data:`), 데이터의 타입을 가리키는 MIME 타입, 텍스트가 아닌 경우 사용될 부가적인 `base64` 토큰 그리고 데이터 자체 총 네가지 부분으로 구성됩니다.
```

data:[<mediatype>][;base64],<data>
```

`mediatype`이란, MIME type을 말합니다(JPEG 이미지의 경우 `'image/jpeg'`). 만약 생략된다면, 기본 값으로 `text/plain;charset=US-ASCII`이 사용됩니다.

데이터에 RFC 3986에 예약된 문자로 정의된 문자가 포함되어 있거나, 공백 문자, 개행 문자 또는 기타 인쇄할 수 없는 문자가 포함되어 있는 경우, 해당 문자는 URL 인코딩된 문자여야 합니다.

데이터가 텍스트인 경우, 단순히 텍스트를 (포함된 문서 유형에 따라 적합한 엔티티 혹은 이스케이프를 사용하여) 포함할 수 있습니다. 그게 아니라면, base64로 인코딩된 이진 데이터를 포함하기 위해 `base64`를 지정할 수 있습니다. MIME 유형에 대한 자세한 내용은 여기 및 여기에서 확인할 수 있습니다.

몇 가지 예제입니다.

`data:,Hello%2C%20World!`

간단한 text/plain 데이터 `Hello, World!`, 쉼표는 `%2C`로 URl 인코딩되고 공백 문자는 `%20`으로 표시됩니다.

`data:text/plain;base64,SGVsbG8sIFdvcmxkIQ==`

위 예제의 base64 인코딩 버전

`data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E`

`<h1>Hello, World!</h1>`인 HTML 문서

`data:text/html,%3Cscript%3Ealert%28%27hi%27%29%3B%3C%2Fscript%3E`

`<script>alert('hi');</script>` JavaScript 경고문을 실행하는 HTML 문서입니다. 닫기 스크립트 태그가 필요하다는 것을 기억하세요.

base64 포맷으로 데이터 인코딩하기
---------------------

Base64는 이진 데이터를 ASCII 문자열 형식으로 기수-64 표현으로 변환하여 나타내는 이진-텍스트 인코딩 체계 그룹입니다. ASCII 문자로만 구성되므로 base64 문자열은 일반적으로 URL로부터 안전하므로 데이터 URL에서 데이터를 인코딩하는 데 사용할 수 있습니다.

### JavaScript에 인코딩하기

Web API에는 Base64로 인코딩하거나 디코딩하는 기본 메서드가 있습니다.

### Unix System에 인코딩하기

Linux 및 macOS 시스템의 Base64 인코딩은 명령줄 `base64`(또는 대안으로 `-m` 인수가 포함된 `uuencode` 유틸리티)를 사용하여 수행할 수 있습니다.

```bash
echo -n hello|base64
# 콘솔에 찍히는 결과: aGVsbG8=

echo -n hello>a.txt
base64 a.txt
# 콘솔에 찍히는 결과: aGVsbG8=

base64 a.txt>b.txt
# b.txt에 찍히는 결과: aGVsbG8=
```

### Windows에 인코딩하기

Windows에서는 PowerShell의 Convert.ToBase64String을 사용하여 Base64 인코딩을 수행할 수 있습니다.
```

[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello"))
# b.txt에 찍히는 결과: aGVsbG8=
```

또는, GNU/Linux 셸(예, WSL)은 `base64` 유틸리티를 제공합니다.

```bash
bash$ echo -n hello | base64
# 콘솔에 찍히는 결과: aGVsbG8=
```

일반적인 문제점
--------

이 섹션에서는 `데이터` URL를 만들고 사용할 때 일반적으로 발생하는 문제점들에 대해 설명합니다.

```html
data:text/html,lots of text…<p><a name%3D"bottom">bottom</a>?arg=val</p>
```

내용이 다음과 같은 HTML 리소스를 나타냅니다.

```html
lots of text…
<p><a name="bottom">bottom</a>?arg=val</p>
```

구문

`데이터` URL를 위한 문법은 매우 간단하지만, "data" 세그먼트 앞에 콤마를 넣는 것을 쉽게 잊거나 데이터를 base64 형식으로 부정확하게 인코딩하는 경우가 있습니다.

HTML 내에 포맷시키기

`데이터` URL는 동봉된 문서의 너비에 비례할 가능성이 높은 파일 내에 파일을 제공하게 됩니다. URL로 `데이터`를 공백 문자(라인 피드, 탭 혹은 스페이스)을 사용해 포맷이 가능해야 하지만 base64 인코딩을 사용할 때 일어나는 실질적인 문제가 있습니다.

길이 제한

브라우저들은 데이터의 개별적인 최대 길이를 제공해야 할 의무가 없습니다. 예를 들어, Opera 11 브라우저는 URL을 65535자로 제한하여, `data` URL을 65529 문자로 제한합니다.(MIME 타입을 지정하지 않고 plain `data`를 사용한다면, 소스가 아닌 인코딩된 데이터의 길이는 65529자가 됩니다). Firefox 버전 97 이상에서는 최대 32MB의 `data` URL을 지원합니다(97 이전에는 한도가 256MB에 비슷했습니다). Chromium 객체는 512MB가 넘는 URL에, Webkit(Safari)은 2048MB가 넘는 URL에 적용됩니다.

오류 처리의 부족

미디어 내의 유효하지 않은 매개변수들 또는 '`base64`'를 지정할 때 오타들은 무시되지만 오류가 발생하지는 않습니다.

쿼리 문자열에 대한 미지원 등

데이터 URL의 데이터 일부는 불명확해서 데이터 URL를 이용해 쿼리 문자열(`<url>?parameter-data` 문법을 이용한 페이지 특정의 파라메터)을 사용하려는 시도는 URL이 나타내는 데이터 내에 쿼리 문자열을 포함하게 됩니다.

보안 이슈

많은 보안 문제(예, 피싱)가 데이터 URL과 연관되어 있으며, 브라우저의 최상위 수준에서 해당 URL로 이동합니다. 이 문제를 완화하기 위해 `data:` URL에 대한 최상위 탐색은 모든 최신 브라우저에서 차단됩니다. 자세한 내용은 Mozilla 보안 팀의 이 블로그 포스트를 참조하세요.

명세서
---

| Specification |
| --- |
| The "data" URL scheme # section-2 |

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

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

같이 보기
-----

* Base64
* URL 인코딩
* `atob()`
* `btoa()`
* CSS `url()` (en-US)
* URI