recursal/MDN huggingface dataset:
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
=================

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

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

응답헤더 **`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
=========

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

**`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`** 응답 헤더는 브라우저가 지정된 리소스에 대한 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
================

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

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

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

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

**`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`** 요청 헤더는 서버의 사용자 에이전트임을 증명하는 자격을 포함하여, 보통 서버에서 `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`\*\*헤더는 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
================

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

**`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.
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`