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

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

요청 헤더 **`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
====

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

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

요청 헤더 **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
======

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

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

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

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 중에서 선택하기
=======================

웹 사이트 소유자들이 반복해서 하게 되는 질문은 비-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 주소창에서 사람들이 입력하는 것들의 현황
Resource URLs
=============

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

`resource:` 스키마가 앞에 붙은 URL은 리소스 URL은 Firefox 및 Firefox 브라우저 확장 프로그램에서 내부적으로 리소스를 로드하는 데 사용되지만, 일부 정보는 브라우저가 연결하는 사이트에서도 사용할 수 있습니다.

구문
--

리소스 URL은 접두사 (`resource:`)와 로드하려는 리소스를 가리키는 URL의 두 부분으로 구성됩니다.


```url
resource://<url>
```


예를 들어,


```url
resource://gre/res/svg.css
```


리소스 URL('->')에 화살표가 있으면, 첫 번째 파일이 다음 파일을 로드했음을 의미합니다.


```url
resource://<File-loader> -> <File-loaded>
```


자세한 내용은 웹에서 리소스 식별을 참조하세요.

이 글에서는, 내장 리소스를 가리키기 위해 Firefox에서 내부적으로 사용되는 리소스 URI에 중점을 둡니다.

위협
--

`resource:` URL을 통해 공유된 정보 중 일부는 다음에서 사용할 있기 때문입니다. 웹사이트, 웹페에지는 내부 스크립트를 실행하고 심각한 보안 및 개인정보 보호 문제가 될 수 있는, 기본 환경 설정을 포함하여 Firefox의 내부 리소스를 검사할 수 있습니다.

예를 들어, Browserleaks의 스크립트는 사이트에서 실행할 수 있는 간단한 스크립트로 조회할 때 Firefox가 공개하는 내용을 강조합니다(https://browserleaks.com/firefox#more에서 코드를 찾을 수 있습니다).

firefox.js 파일은 기본 설정된 이름과 값을 pref() 함수에 전달합니다. 예를 들어,


```url
http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575
```


웹사이트는 이 `pref()` 함수를 재정의하고 `resource:///defaults/preferences/firefox.js` 스크립트를 사용하여 Firefox 기본 환경 설정을 쉽게 수집할 수 있습니다.

또한, 기본 설정의 일부 기본값은 플랫폼 및 로케일 등 웹사이트가 이러한 정보들을 사용하여 개별 사용자를 식별할 수 있는 정보를 기반으로 빌드 구성마다 다릅니다.

해결책
---

이 문제를 해결하기 위해, Mozilla 리소스 로드 동작을 변경했습니다. Firefox 버그 863246의 URI는 Firefox 57 (Quantum) (en-US)에 포함되었습니다.

과거에는 웹 콘텐츠가 원하는 `resource:` URI가 무엇이든, 즉 Firefox의 내부 리소스뿐만 아니라 확장 프로그램의 자산에도 접근할 수 있었습니다. 이제 이 행위는 기본적으로 금지되어 있습니다.

그러나 Firefox가 웹 콘텐츠의 리소스를 로드하는 것은 여전히 특정 상황에서는 필요한 부분입니다. 예를 들어, 소스 보기 페이지(View Page Source 또는 View Selection Source)를 열었을 때, `resource:` URI를 통해 `viewsource.css`가 필요하다는 것을 알 수 있습니다. 웹 콘텐츠에 노출되어야 하는 리소스에는 격리되어 있으며 민감하지 않은 리소스만 포함되어 있는 `resource://content-accessible/`이라는 새 위치로 이동되었습니다. 이러한 방법으로 우리는 필수적인 것을 유지할 수 있고, 리소스가 노출되어 대부분의 위협이 없어지게 되었습니다.

**참고:** 웹 및 확장 프로그램 개발자는 더 이상 리소스 URL을 시도하지 않는 것이 좋습니다.
 그들의 사용법은 기껏해야 해키였습니다.
 대부분의 사용법은 작동하지 않습니다.


명세서
---

리소스: 어떤 명세에도 아직 아무것도 정의되지 않았습니다.

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

리소스: 오직 Firefox만 지원합니다.

같이 보기
-----

* Web에서 리소스를 식별하기
* URL이란 무엇인가?
* IANA URI 체계 목록 (`resource:`은 이곳에서 다룹니다)
CORS errors
===========

교차 출처 자원 공유 (CORS)는 서버가 same
 origin 정책(same-origin policy)을 완화할 수 있게 해 주는 표준입니다. 이는 일부
 교차 출처 요청은 명시적으로 허용하고 다른 요청은 거부하는 데 사용됩니다. 예를 들어서, 어떤 사이트가 embeddable service를 제공하는 경우, 특정 제한을
 완화하는 것이 필요할 수 있습니다. CORS 설정을 세팅하는 것은 그리 쉬운 일이 아니며, 도전일 수 있습니다. 이 페이지에서는, 몇 가지 일반적인 CORS 에러 메시지를 소개하고 그에 맞는 해결법을
 알아보겠습니다.

 만약 CORS 설정이 제대로 세팅되어 있지 않다면, 브라우저 콘솔에는 다음과 같은 메시지가 표시될 것입니다:
 `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"`
 이 메시지는 CORS 보안 규칙 위반으로 인해 요청이 차단되었음을 알려줍니다. 이것은 꼭 설정 실수라고 볼 수는 없습니다.
 사실은 해당 요청이 유저 쪽의 웹 어플리케이션과 외부 서비스에 의해 거부당했을 수 있습니다. 하지만 만약 엔드포인트가 사용 가능한 걸로 확인된다면, 약간의 디버깅이 필요 할 수 있습니다.

이슈 파악하기
-------

CORS 설정 이슈를 근본적으로 이해하려면 어떤 요청이 문제이고 왜 문제인지를 파악할 필요가 있습니다. 다음 단계들을 따라하면 도움이 될 것입니다.

1. 웹사이트나 웹앱으로 이동하여 Developer Tools을 여세요.
2. 실패한 요청을 재현하고 나서 CORS 위반 에러 메시지가 떴다면 console을 확인하세요. 메시지는 다음과 같을 겁니다:

![Firefox console showing CORS error](/ko/docs/Web/HTTP/CORS/Errors/cors-error2.png)

에러 메시지 내용은 다음과 비슷할 수 있습니다.
```

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).
```


**참고:** \*\*Note:\*\*보안상의 이유로, CORS 요청에서 정확히 무엇을 위반했는지에 대한 사항은 *JavaScript 코드상에서 사용할 수 없습니다.* 코드상에서 알 수 있는 것은 에러가 발생했다는 것 뿐입니다.
 정확히 무엇이 잘못됐는지 파악하려면 브라우저 콘솔을 살피는 수밖에 없습니다.


CORS 에러 메시지
-----------

 Firefox 콘솔은 CORS에 의해 요청이 실패했을 때 메시지를 출력합니다. 에러내용의 일부분은 "Reason"에 관한 메시지로서 무엇이 잘못되었는지에 대한 힌트를 제공합니다.
 "Reason" 메시지들이 아래에 정리되어 있으니 더 자세한 에러에 대한 설명과 솔루션을 보고 싶으시다면 링크로 이동하세요.

* Reason: CORS disabled
* Reason: CORS request did not succeed
* Reason: CORS header 'Origin' cannot be
added
* Reason: CORS request external redirect
not allowed
* Reason: CORS request not http
* Reason: CORS header
'Access-Control-Allow-Origin' missing
* Reason: CORS header
'Access-Control-Allow-Origin' does not match 'xyz'
* Reason: Credential is not supported if the
CORS header 'Access-Control-Allow-Origin' is '\*'
* Reason: Did not find method in CORS header
'Access-Control-Allow-Methods'
* Reason: expected 'true' in CORS header
'Access-Control-Allow-Credentials'
* Reason: CORS preflight channel did not
succeed
* Reason: invalid token 'xyz' in CORS header
'Access-Control-Allow-Methods'
* Reason: invalid token 'xyz' in CORS header
'Access-Control-Allow-Headers'
* Reason: missing token 'xyz' in CORS
header 'Access-Control-Allow-Headers' from CORS preflight channel
* Reason: Multiple CORS header
'Access-Control-Allow-Origin' not allowed
더보기
---

* Glossary: CORS
* CORS introduction
* Server-side CORS settings (en-US)
* CORS enabled image
* CORS settings attributes (en-US)
* https://www.test-cors.org – page to test CORS requests