recursal/MDN huggingface dataset:
OPTIONS
=======

**HTTP `OPTIONS` 메서드**는 주어진 URL 또는 서버에 대해 허용된 통신 옵션을 요청합니다. 클라이언트는 이 방법으로 URL을 지정하거나 별표(`*`)를 지정하여 전체 서버를 참조할 수 있습니다.

|  |  |
| --- | --- |
| 요청에 본문이 있음 | 아니요 |
| 성공적인 응답에 본문이 있음 | 예 |
| 안전함 | 예 |
| 멱등성 | 예 |
| 캐시 가능 | 아니요 |
| HTML 폼에서 허용됨 | 아니요 |

구문
--


```http
OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
```

예제
--

### 허용된 요청 매서드 식별하기

서버가 지원하는 요청 방법을 찾으려면 아래와 같이 `curl` 명령어을 사용하여 `OPTIONS` 요청을 보내볼 수 있습니다.


```bash
curl -X OPTIONS https://example.org -i
```


그럼 응답은 허용된 메서드를 가지고 있는 `Allow` 헤더가 있습니다.


```http
HTTP/1.1 200 No Content
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
```

### CORS 사전 요청

CORS에서 사전 요청은 `OPTIONS` 메서드를 통해 전송되므로 요청을 보낼 수 있는 경우라면 서버가 응답할 수 있습니다. 이번 예제에서는 다음 매개변수에 대한 권한을 요청합니다.

* 사전 요청에서 전송되는 `Access-Control-Request-Method` 헤더는 서버에 실제 요청이 전송될 때 `POST` 메서드가 있음을 알려줍니다.
* `Access-Control-Request-Headers` 헤더는 서버에 실제 요청이 전송될 때 `X-PINGOTHER`와 `Content-Type` 헤더가 있음을 알려줍니다.


```http
OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.example
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
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```


이제 서버는 아래와 같은 상황에서 요청을 수락할 때 응답할 수 있습니다. 이 예제에세 서버의 응답은 다음과 같습니다.

`Access-Control-Allow-Origin`

`https://foo.example` 출처는 다음을 통해 `bar.example/resources/post-here/` URL을 요청할 수 있습니다.

`Access-Control-Allow-Methods`

`POST`, `GET` 그리고 `OPTIONS`는 이 URL에 허용되는 메서드입니다. (이 헤더는 `Allow` 헤더와 유사하지만 CORS에만 사용됩니다.)

`Access-Control-Allow-Headers`

`X-PINGOTHER` 및 `Content-Type`은 URL에 대해 허용되는 요청 헤더입니다.

`Access-Control-Max-Age`

위 권한은 86,400초(1일) 동안 캐시될 수 있습니다.


```http
HTTP/1.1 200 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
```

상태 코드
-----

`200` OK와 `204` No Content 모두 허용되는 상태 코드이지만 일부 브라우저는 `204 No Content`가 실제 리소스에 적용된다고 잘못 판단하여 리소스를 가져오기 위한 다음 요청을 보내지 않습니다.

명세서
---

| Specification |
| --- |
| HTTP Semantics # OPTIONS |

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

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

같이 보기
-----

* `Allow` 헤더
* CORS
PATCH
=====

**HTTP PATCH** 메소드는 리소스의 부분적인 수정을 할 때에 사용됩니다.

HTTP `PUT` 메소드는 문서 전체의 완전한 교체만을 허용합니다. 반면 `PATCH` 메소드는 `PUT` 메소드와 달리 멱등성을 가지지 않는데, 이는 동일한 patch 요청이 다른 결과를 야기할 수도 있음을 뜻합니다. 하지만 PATCH를 PUT과 같은 방식으로 사용함으로써 멱등성을 가지게 할 수도 있습니다.

`PATCH` (혹은 `PUT`)는 다른 리소스에게 부수효과(side-effects)를 일으킬 가능성이 있습니다.

서버가 `PATCH`를 지원하는지 알 수 있게끔 하기 위해, 서버는 `Allow` 리스트 혹은 `Access-Control-Allow-Methods` (for CORS) 응답 헤더를 통해 이를 명시할 수 있습니다.

PATCH가 허용되는지 확인할 수 있는 또 다른 (암묵적인)지표로 `Accept-Patch`의 존재 유무를 들 수 있는데, 이를 통해 patch 문서 양식이 서버에 받아 들여졌음을 알 수 있습니다.

|  |  |
| --- | --- |
| Request has body | Yes |
| Successful response has body | Yes |
| Safe | No |
| Idempotent | No |
| Cacheable | No |
| Allowed in HTML forms (en-US) | No |

Syntax
------
```

PATCH /file.txt HTTP/1.1
```

Example
-------

### Request


```http
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]
```

### Response

성공적인 응답은 2xx 상태 코드를 통해서 확인할 수 있습니다.

아래의 예시에서는 `204` 응답이 사용되었는데, 이는 응답이 유의미한 body를 전달하고 있지 않기 때문입니다. {HTTPStatus("200")}} 응답에서는 body에 유의미한 데이터가 포함되어 있음을 유추할 수 있습니다.
```

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
```
명세서
---

| Specification |
| --- |
| RFC 5789  |

See also
--------

* `204`
* `Allow`, `Access-Control-Allow-Methods`
* `Accept-Patch` – specifies the patch document formats accepted by the server.
GET
===

**HTTP `GET` 메서드**는 특정한 리소스를 가져오도록 요청합니다. `GET` 요청은 데이터를 가져올 때만 사용해야 합니다.

**참고:** > `GET` 요청에 본문이나 페이로드가 담겨있으면 명세에는 금지되어있지 않지만, 의미가 정의되지 않아 기존에 존재하는 구현체에게 요청을 거부당할수 있습니다. 이러한 이유로 `GET` 요청에는 본문이나 페이로드를 담지 않는 것이 바람직합니다.


|  |  |
| --- | --- |
| 요청에 본문 존재 | 아니오 |
| 성공 응답에 본문 존재 | 예 |
| 안전함 | 예 |
| 멱등성 | 예 |
| 캐시 가능 | 예 |
| HTML 양식에서 사용 가능 | 예 |

구문
--
```

GET /index.html
```

명세
--

| Specification |
| --- |
| HTTP Semantics # GET |

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

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

같이 보기
-----

* HTTP 헤더
* `Range`
* `POST`
DELETE
======

**HTTP `DELETE` 메서드**는 지정한 리소스를 삭제합니다.

|  |  |
| --- | --- |
| 요청에 본문 존재 | May |
| 성공 응답에 본문 존재 | May |
| 안전함 | No |
| 멱등성 | Yes |
| 캐시 가능 | No |
| HTML 양식에서 사용 가능 | No |

구문
--
```

DELETE /file.html HTTP/1.1
```

예제
--

### 요청
```

DELETE /file.html HTTP/1.1
```

### 응답

`DELETE` 메서드를 성공적으로 적용한 후에 사용할 수 있는 응답 상태 코드는 다음과 같이 몇 가지가 있습니다.

* 아마도 명령을 성공적으로 수행할 것 같으나 아직은 실행하지 않은 경우 `202` (`Accepted`) 상태 코드.
* 명령을 수행했고 더 이상 제공할 정보가 없는 경우 `204` (`No Content`) 상태 코드.
* 명령을 수행했고 응답 메시지가 이후의 상태를 설명하는 경우 `200` (`OK`) 상태 코드.
```

HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT

<html>
  <body>
    <h1>File deleted.</h1>
  </body>
</html>
```

명세
--

| Specification |
| --- |
| HTTP Semantics # DELETE |

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

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

같이 보기
-----

* HTTP 상태: `200`, `202`, `204`
Accept-Patch
============

**`Accept-Patch`** 응답 HTTP 헤더는 서버가 PATCH 요청에서 어떤 미디어 유형을 이해할 수 있는지를 알려줍니다.

메서드에 대한 응답으로 **`Accept-Patch`** 를 반환하면 Request-URI로 식별된 리소스에서 PATCH가 허용됨을 의미합니다. 두 가지 일반적인 경우가 이에 해당합니다.

지원되지 않는 미디어 유형이 포함된 패치 요청을 수신하는 서버는 `415` `Unsupported Media Type`과 하나 이상의 지원되는 미디어 유형을 참조하는 Accept-Patch 헤더로 응답할 수 있습니다.

**참고:**

* IANA 레지스트리는 공식 콘텐츠 인코딩의 전체 목록을 유지 관리합니다.
* 표준은 아니지만 다른 두 가지 콘텐츠 인코딩인 `bzip`과 `bzip2`가 사용되기도 합니다. 이들은 이 두 가지 UNIX 프로그램에서 사용하는 알고리즘을 구현합니다. 첫 번째는 특허 라이선스 문제로 인해 사용이 중단되었습니다.


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

구문
--


```http
Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

지시어
---

없습니다.

예제
--


```http
Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

명세서
---

| Specification |
| --- |
| RFC 5789 # section-3.1 |

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

브라우저 호환성은 이 헤더와 관련이 없습니다. 헤더는 서버에서 전송되며 사양은 클라이언트 동작을 정의하지 않습니다.

같이 보기
-----

* HTTP 메서드 `PATCH`
* HTTP 시맨틱 및 컨텍스트 RFC 7231, 섹션 4.3.4: PUT
Pragma
======

HTTP/1.0 의 **`Pragma`** 헤더는 요청-응답 체인에 다양한 영향을 줄 수 있는 구현관련 헤더이다. 이것은 HTTP/1.0 버전에서 HTTP/1.1 버전의 `Cache-Control` 헤더가 생기기 전 그것과 동일한 역할을 하는 대용 헤더로 사용되었다.

**참고:** `Pragma` 는 HTTP 응답에서 명시되지 않았던 헤더여서 일반적인 HTTP/1.1 의 `Cache-Control` 헤더의 신뢰할만한 대체재로 사용될수는 없다. 비록 그것이 응답에서 `Cache-Control` 헤더가 생략되었을 시, `Cache-Control: no-cache` 와 동일하게 효과를 주긴 하지만 말이다. `Pragma` 헤더는 HTTP/1.0 를 사용하는 클라이언트들만을 위한 비공식적인 호환성을 위해서 사용하는것이 옳다.


|  |  |
| --- | --- |
| Header type | General header, 그러나 응답 동작은 정해지지
 않아서 구현 방식에 따른다.
  |
| Forbidden header name | 아님 |
| CORS-safelisted response-header | 맞음 |

문법
--
```

Pragma: no-cache
```

디렉티브
----

no-cache

`Cache-Control: no-cache` 와 같다. 캐시가 캐시 복사본을 릴리즈 하기전에 원격 서버로 요청을 날려 유효성 검사를 강제하도록 한다.

예제
--
```

Pragma: no-cache
```

명세서
---

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

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

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

그외 볼것들
------

* `Cache-Control`
* `Expires`
Expect
======

**`Expect`** HTTP 요청 헤더는 요청을 적절하게 처리하기 위해 서버가 반환할 기대값을 나타냅니다.

명세에 정의된 유일한 기대값인 `Expect: 100-continue`에 대해, 서버는 다음과 같이 응답합니다:

* `100` 헤더에 포함된 정보가, 즉시 성공으로 응답하기 충분할 때
* `417` (en-US) (Expectation Failed) 기대값을 충족하지 못했거나; 어쨌든 4xx 상태일 때

예를들어, 요청의 `Content-Length` 값이 너무 크다면 서버는 이를 거절할 수도 있습니다.

일반적인 브라우저는 `Expect` 헤더를 전송하지 않지만, cURL과 같은 몇가지 클라이언트들은 전송하는 것이 기본값입니다.

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

Syntax
------

현재는 "100-continue" 를 제외하고 어떤 기대값도 정의되어있지 않습니다.
```

Expect: 100-continue
```

Directives
----------

100-continue

Informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a `100` (Continue) interim response.

Examples
--------

### Large message body

클라이언트는 `Expect` 헤더가 포함된 요청을 전송하고 메시지 바디를 전송하기 이전에 서버의 응답을 기다립니다.
```

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


이제 서버는 요청 헤더를 확인하고 {HTTPStatus("100")}} (Continue) 상태를 응답하여 클라이언트가 계속해서 메시지 바디를 전송하도록 안내하거나, `417` (en-US) (Expectation Failed) 상태를 응답하여 어떠한 기대값도 충족되지 않도록 합니다.

명세서
---

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

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

No common browsers are known to send this header.

See also
--------

* `417` (en-US) `Expectation Failed`
* `100` `Continue`
Alt-Used
========

`Alt-Used` HTTP 헤더는 `Host` HTTP 헤더 필드가 원본의 포트와 호스트를 식별하는 것처럼, 사용 중인 대체 서비스를 식별하기 위해 요청에서 사용됩니다.

이는 프로토콜이 사용 중인 후에 이 정보를 도입하는 것은 문제가 있는 것으로 입증되었기 때문에, 대체 서비스가 루프를 감지하고, 로드 밸런싱을 위해 트래픽을 구분하고, 일반적으로 트래픽의 의도된 목적지를 식별할 수 있도록 하기 위한 것입니다.

클라이언트가 요청에 대체 서비스를 사용하는 경우, `Alt-Used` HTTP 헤더를 사용하여 서버에 이를 표시할 수 있습니다.

구문
--


```http
Alt-Used: <host>:<port>
```

지시어
---

<host>

서버의 도메인 이름입니다.

<port> Optional

서버가 수신 대기 중인 TCP 포트 번호입니다.

예제
--


```http
Alt-Used: alternate.example.net
```

같이 보기
-----

* `Alt-Svc`
* `Host`
Accept-Post
===========

**`Accept-Post`** 응답 HTTP 헤더는 HTTP 포스트 요청에 대해 서버가 수락하는 미디어 유형을 알립니다.

모든 메소드에 대한 응답으로 **`Accept-Post`** 를 사용하면 요청된 리소스에서 `POST`가 허용됨을 의미합니다. 헤더의 모든 문서/미디어 형식은 해당 문서 형식이 허용됨을 추가로 나타냅니다.

예를 들어, 지원되지 않는 미디어 유형이 포함된 `POST` 요청을 수신하는 서버는 `415` `Unsupported Media Type`과 하나 이상의 지원되는 미디어 유형을 참조하는 **`Accept-Post`** 헤더를 사용하여 응답할 수 있습니다.

**참고:** IANA 레지스트리는 공식 콘텐츠 인코딩의 전체 목록을 유지 관리합니다.


|  |  |
| --- | --- |
| 헤더 유형 | 응답 헤더 |
| 금지된 헤더 이름 | 예 |

구문
--


```http
Accept-Post: <MIME\_type>/<MIME\_subtype>
Accept-Post: <MIME\_type>/\*
Accept-Post: \*/\*
```


**참고:** `Accept-Post` 헤더는 기본 설정 개념이 없다는 점(즉, `q` 인수가 없다는 점)을 제외하면 `Accept`와 동일한 방식으로 미디어 범위를 지정합니다. 이는 `Accept-Post`가 응답 헤더인 반면 `Accept`는 요청 헤더이기 때문입니다.

지시어
---

없습니다.

예제
--


```http
Accept-Post: application/example, text/example
Accept-Post: image/webp
Accept-Post: \*/\*
```

명세서
---

| Specification |
| --- |
| Linked Data Platform # header-accept-post |

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

브라우저 호환성은 이 헤더와 관련이 없습니다. 헤더는 서버에서 전송되며 사양은 클라이언트 동작을 정의하지 않습니다.

같이 보기
-----

* HTTP 메서드 `POST`
* HTTP 시맨틱 및 컨텍스트 RFC 7231, 섹션 4.3.3: POST
Content-Range
=============

**`Content-Range`** HTTP 응답 헤더는 전체 바디 메시지에서 부분 메시지가 속한 위치를 알려줍니다.

|  |  |
| --- | --- |
| 헤더 타입 | Response header,
 Payload header |
| 금지된 헤더 이름 | 아니오 |
| CORS-safelisted
 response-header | 아니오 |
| CORS-safelisted response-header | 아니오 |

문법
--


```http
Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/\*
Content-Range: <unit> \*/<size>
```

지시자
---

<unit>

단위는 범위를 지정합니다. 보통 `bytes`를 사용합니다.

<range-start>

범위 요청의 시작을 알려주는 정수 단위.

<range-end>

범위 요청의 끝을 알려주는 정수 단위.

<size>

문서의 총 크기(또는 모른다면 `'*'`)

예제
--


```http
Content-Range: bytes 200-1000/67589
```

명세서
---

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

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

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

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

* `If-Range`
* `Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`
Access-Control-Allow-Headers
============================

**`Access-Control-Allow-Headers`** 는 `Access-Control-Request-Headers`를 포함하는 preflight request의 응답에 사용되는 헤더로, 실제 요청때 사용할 수 있는 HTTP 헤더의 목록을 나열합니다.

요청에 `Access-Control-Request-Headers` 헤더가 포함되어 있을 경우, 이 헤더를 포함하여야 합니다.

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

구문
--
```

Access-Control-Allow-Headers: <header-name>[, <header-name>]*
Access-Control-Allow-Headers: *
```

지시자
---

`<header-name>`

지원하는 헤더의 이름입니다. 쉼표로 구분하여 원하는 만큼 헤더를 나열할 수 있습니다.

`*` (와일드카드)

"`*`" 값은 자격 증명이 없는 요청(쿠키 혹은 HTTP 인증 정보가 없는 요청)일 경우 특수한 와일드 카드로 처리됩니다. 자격증명을 포함하는 경우 단순히 "`*`"라는 이름을 갖는 특별한 의미가 없는 헤더로 취급됩니다. 단, `Authorization` 헤더는 와일드카드에 포함되지 않으며 명시적으로 나열해야 합니다.

예제
--

### 사용자 정의 헤더

다음은 `Access-Control-Allow-Headers` 헤더가 어떤 식으로 작성되는지에 대한 예시입니다. CORS에서 안전한 헤더외에도 X-Custom-Header라는 사용자 정의 헤더가 서버에 대한 CORS 요청에 의해 지원됨을 나타냅니다.
```

Access-Control-Allow-Headers: X-Custom-Header
```

### 여러 개의 헤더

이 예시는 여러 개의 헤더를 지정할 때 Access-Control-Allow-Headers가 어떤 식으로 작성되는지 보여줍니다.
```

Access-Control-Allow-Headers: X-Custom-Header, Upgrade-Insecure-Requests
```

### Preflight 요청 예시

사전 요청에서 `Access-Control-Allow-Headers` 이 사용된 경우의 예제를 보도록 합시다.

#### 요청

이 Preflight 요청은 Preflight 요청 헤더인 `Access-Control-Request-Method`, `Access-Control-Request-Headers` 및 `Origin`, 이 세가지 Preflight 요청 헤더를 포함하는 `OPTIONS` 요청입니다.
```

OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org
```


#### 응답

만약 서버가 `DELETE` 메소드에 CORS 요청을 허용한다면 `Access-Control-Allow-Methods`에 DELETE, 그리고 다른 지원하는 메소드를 포함하여 응답합니다.
```

HTTP/1.1 200 OK
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400
```


요청된 메소드가 지원되지 않으면 서버는 오류로 응답합니다.

명세
--

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

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

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

함께 보기
-----

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers`
From
====

**`From`** 요청 헤더는 요청한 사용자 에이전트를 제어하는 인간 사용자의 인터넷 이메일을 포함합니다.

만약 당신이 (예를 들어 크롤러와 같은) 로보틱 사용자 에이전트를 실행하고 있다면, `From` 헤더를 반드시 전송해야 하며, 로봇이 한도를 초과하거나 원하지 않으며, 유효하지 않은 요청을 전송하고 있는 경우처럼 서버 상에 문제를 일으키고 있다면 당신에게 해당 이메일로 연락이 가능해야 합니다.

**경고:** 접근 제어 혹은 인증을 위해 `From` 헤더를 사용해서는 안됩니다.


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

문법
--
```

From: <email>
```

디렉티브
----

<email>

기계가 사용 가능한 이메일 주소.

예제
--
```

From: webmaster@example.org
```

명세
--

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

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

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

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

* `Host`
Range
=====

**`Range`** HTTP 요청 헤더는 서버에게 문서의 일부분만 돌려주어야 한다는 것을 알려줍니다. `Range` 헤더를 통해 여러 부분을 한번에 요청할 수 있으며, 서버는 이러한 범위에 대해 문서의 여러 부분을 돌려보내줄 것입니다. 만약 서버가 돌려 보낸다면, `206` `Partial Content`를 응답으로 사용할 것입니다. 만약 범위가 유효하지 않다면, 서버는 `416` `Range Not Satisfiable` 에러를 보낼 것입니다. 또한 서버는 `Range` 헤더를 무시하고 `200` 상태 코드와 함께 전체 문서를 돌려줄 수 있습니다.

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

문법
--
```

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>
```

지시자
---

<unit>

범위를 결정하는 단위. 보통 `bytes`.

<range-start>

범위 요청의 시작 지점을 알리는 단위를 뜻하는 정수.

<range-end>

요청한 범위의 끝을 알리는 단위를 의미하는 정수. 이 값은 옵션으로 사용할 수 있으며, 생략한다면 문서의 끝부분을 요청의 끝으로 사용함.

예제
--
```

Range: bytes=200-1000, 2000-6576, 19000-
```

기술 사양
-----

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

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

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

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

* `If-Range`
* `Content-Range`
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`
If-Modified-Since
=================

**`If-Modified-Since`** HTTP 요청 헤더는 조건부 요청으로 서버는 지정된 날짜 이후 수정 된 경우에 `200` 과 함께 요청된 리소스를 돌려 줍니다. 만약 수정되지 않는 리소스에 대한 요청시, 리소스 없이 `304` 응답을 하게 됩니다. 이전 요청의 `Last-Modified` 응답 헤더는 마지막으로 수정 한 날짜를 포함합니다.`If-Modified-Since`는 `If-Unmodified-Since` 와는 다르게 `GET` 또는 `HEAD` 에서만 쓸수 있습니다.

서버가 `If-None-Match`를 지원하지 않는 한 `If-None-Match` 를 함께 사용시 무시 됩니다.

가장 일반적인 사용예로, `ETag` 가 없는 캐시된 엔티티로 업데이트 합니다.

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

문법
--
```

If-Modified-Since: <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 숫자의 분, 예: "04" 또는 "59.

<minute>

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

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

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

예제
--
```

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

기술 사양
-----

| 기술 사양 | 제목 |
| --- | --- |
| RFC 7232, 섹션 3.3: If-Modified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

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

* `ETag`
* `If-Unmodified-since`
* `If-Match` (en-US)
* `If-None-Match`
* `304` `Not Modified`
X-Forwarded-Proto
=================

**`X-Forwarded-Proto`** (XFP) 헤더는 클라이언트가 당신의 프록시 또는 로드 밸런서에 접속하는데에 사용했던 프로토콜(HTTP 또는 HTTPS)이 무엇인지 확인하는 사실상의 표준 헤더 입니다. 당신의 서버 접근 로그들은 서버와 로드 밸런서 사이에서 사용된 프로토콜을 포함하고 있습니다. 그러나 클라이언트와 로드밸런서에 사용한 프로토콜은 포함되어 있지 않습니다. 클라이언트와 로드밸런서 간의 사용된 프로토콜을 확인하기 위해서, `X-Forwarded-Proto 요청 헤더가 사용되어 질 수 있습니다.`

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

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

Syntax
------
```

X-Forwarded-Proto: <protocol>
```

Directives
----------

<protocol>

넘겨져야 할 프로토콜 (http 또는 https).

Examples
--------
```

X-Forwarded-Proto: https
```


그 외의 비표준 폼:
```

# Microsoft
Front-End-Https: on

X-Forwarded-Protocol: https
X-Forwarded-Ssl: on
X-Url-Scheme: https
```

Specifications
--------------

어떠한 현재의 명세에도 포함되어 있지 않습니다. 이 헤더의 표준화된 버전은 `Forwarded` 입니다..

See also
--------

* `Forwarded`
* `X-Forwarded-For`
* `X-Forwarded-Host`
Keep-Alive
==========

**비표준:** 이 기능은 비표준이므로 실제 프로덕션에서 사용하지 마세요. 모든 사용자 환경에서 작동하지 않을 수 도 있으며, 미래에 호환성 문제가 생길 수 있습니다.

**`Keep-Alive`** 일반 헤더는 송신자가 연결에 대한 타임아웃과 요청 최대 개수를 어떻게 정했는지에 대해 알려줍니다.

**참고:** `Connection` 헤더는 이 헤더를 위해 어떤 의미든 갖도록 "keep-alive"로 설정되어야 합니다. 또한, `Connection`과 `Keep-Alive`는 HTTP/2에서 무시됩니다; 연결 관리는 해당 프로토콜 내에서 다른 메커니즘에 의해 처리됩니다.


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

문법
--
```

Keep-Alive: parameters
```

디렉티브
----

*파라메터*

쉼표로 구분된 파라메터 목록으로, 각각 등호('=')로 구분되는 식별자와 값으로 구성됩니다. 다음은 사용 가능한 식별자들입니다:

* `timeout`: 유휴 연결이 계속 열려 있어야 하는 *최소한의* 시간(초 단위)을 가르킵니다. keep-alive TCP 메시지가 전송 계층에 설정되지 않는다면 TCP 타임아웃 이상의 타임아웃은 무시된다는 것을 알아두시기 바랍니다.
* `max`: 연결이 닫히기 이전에 전송될 수 있는 최대 요청 수를 가리킵니다. 만약 `0`이 아니라면, 해당 값은 다음 응답 내에서 다른 요청이 전송될 것이므로 비-파이프라인 연결의 경우 무시됩니다. HTTP 파이프라인은 파이프라이닝을 제한하는 용도로 해당 값을 사용할 수 있습니다.

예제
--

Keep-Alive 헤더를 포함하는 응답:
```

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)
```

명세
--

| Specification |
| --- |
| HTTP/1.1 # compatibility.with.http.1.0.persistent.connections |

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

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

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

* `Connection`
* Connection management in HTTP/1.x
Access-Control-Allow-Origin
===========================

**`Access-Control-Allow-Origin`** 응답 헤더는 이 응답이 주어진 origin으로부터의 요청 코드와 공유될 수 있는지를 나타냅니다.

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

구문
--
```

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

지시자
---

`*`

*credential*이 없는 요청들에 와일드카드로써 문자 값 "\*"이 명시될 수 있습니다. 이 값은 브라우저에 리소스에 접근하는 임의의 origin으로부터의 요청 코드를 허용함을 알립니다. 와일드카드를 credential과 함께 사용하려고 하면 오류가 발생합니다.

`<origin>`

origin을 명시합니다. 하나의 origin만 명시될 수 있습니다.

예시
--

브라우저에 리소스에 접근하는 임의의 origin으로부터의 요청을 허용한다고 알리는 응답은 다음을 포함할 것입니다:
```

Access-Control-Allow-Origin: *
```


브라우저에 `https://developer.mozilla.org`으로부터의 요청을 허용한다고 알리는 응답은 다음을 포함할 것입니다:
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```


가능한 `Access-Control-Allow-Origin` 값을 허용된 origin 집합으로 제한하는 것은 요청 헤더의 `Origin`를 검사하는 서버 측 코드가 필요합니다. 이를 허용된 origin 리스트와 비교하고, `Origin` 값이 리스트에 있으면 `Access-Control-Allow-Origin` 값을 `Origin`과 동일한 값으로 설정합니다.

### CORS and caching

서버가 ("`*`" 와일드카드 외에) 명시적인 origin을 `Access-Control-Allow-Origin` 과 함께 응답으로 보내면, 응답은 값이 `Origin`인 `Vary` 응답 헤더 또한 포함해야 합니다 — 브라우저에 서버가 `Origin` 요청 헤더의 값에 따라 다르게 응답할 수 있음을 알리기 위해.
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

### Handling CORS on the server (Java example)

다음의 Java 코드는 CORS 요청 헤더를 설정합니다. 코드가 어떻게 `Access-Control-Allow-Origin` 값을 `Origin` 요청 헤더와 동일한 값을 설정하는지 알아 두십시오.


```java
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

@Component
public class SimpleCORSFilter implements Filter {

private final Logger log = LoggerFactory.getLogger(SimpleCORSFilter.class);

public SimpleCORSFilter() {
    log.info("SimpleCORSFilter init");
}

@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;
    response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
    response.setHeader("Access-Control-Allow-Credentials", "true");
    response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
    response.setHeader("Access-Control-Max-Age", "3600");
    response.setHeader("Access-Control-Allow-Headers", "Content-Type, Accept, X-Requested-With, remember-me");
    chain.doFilter(req, res);
}

@Override
public void init(FilterConfig filterConfig) {
}

@Override
public void destroy() {
}

}
```

명세서
---

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

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

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

참고
--

* `Origin`
* `Vary`
* CORS 문제를 어떻게 해결하나요?
Access-Control-Allow-Methods
============================

**`Access-Control-Allow-Methods`** 헤더는 사전 요청에 대한 응답으로 리소스에 접근할 때 허용되는 메서드를 지정합니다.

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

문법
--


```http
Access-Control-Allow-Methods: <method>, <method>, …
Access-Control-Allow-Methods: \*
```

디렉티브
----

`<method>`

허용된 HTTP 요청 메서드의 목록이며 콤마로 구분됩니다.

`*` (와일드카드)

`*`는 자격 증명이 없는 요청 (쿠키나 HTTP 인증 정보가 없는 요청)에 대해서만 특수 와일드카드 값으로 취급됩니다. 자격 증명이 있는 요청에서는 특별한 의미를 갖지 않고 단순히 "\*"라는 메서드 이름으로 취급됩니다.

예제
--


```http
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: \*
```

명세
--

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

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

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

같이 보기
-----

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`