recursal/MDN huggingface dataset:
Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
=========================================================================

이유
--
```

Reason: Did not find method in CORS header 'Access-Control-Allow-Methods'
```

무엇이 문제인가요?
----------

CORS 요청에서 사용 중인 HTTP 메서드는 응답 `Access-Control-Allow-Methods` 헤더에 의해 지정된 메서드 목록에 포함되어 있지 않습니다. 이 헤더는 CORS를 사용하여 요청에 지정된 URL에 접근할 때 사용할 수 있는 HTTP 메서드의 쉼표로 구분되는 목록입니다. 요청이 다른 메소드를 사용하는 경우에, 이 오류가 발생합니다.

예를 들어, 응답에 다음이 포함된 경우


```http
Access-Control-Allow-Methods: GET,HEAD,POST
```


`PUT` 요청을 사용하려고 하면 이 오류와 함께 실패합니다.

서비스에 접근할 때 코드가 허용된 HTTP 메서드만 사용하는지 확인하세요.

**참고:** 서버의 `Access-Control-Allow-methods` 헤더에 인식되지 않거나 정의되지 않은 메서드 이름이 포함된 경우, 다른 오류가 발생합니다. `Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'`.

See also
--------

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 요청 메서드
Reason: CORS header 'Origin' cannot be added
============================================

이유
--
```

Reason: CORS header 'Origin' cannot be added
```

무엇이 잘못되었는가?
-----------

 사용자 에이전트(user agent)가 필요한 `Origin`
 헤더를 HTTP 요청에 추가할 수 없습니다. 모든 CORS 요청에는 `Origin` 헤더가 있어야 합니다.

예를 들어, JavaScript 코드가 여러 도메인의 콘텐츠에 접근할 수 있는 향상된 권한으로 실행되는 경우에 발생할 수 있습니다.

같이 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개
Reason: CORS disabled
=====================

원인
--
```

원인: CORS 비활성화
```

무엇이 문제인가요?
----------

CORS를 사용해야 하는 요청이 시도되었지만 사용자의 브라우저에서 CORS가 비활성화되어 있습니다. 이 경우 사용자는 브라우저에서 CORS를 다시 켜야 합니다.

 Firefox에서 CORS를 비활성화하는 기본 설정은 `content.cors.disable`입니다.
 `true`로 설정하면 CORS가 비활성화되므로 그럴 때마다 CORS 요청은 항상 실패하고 이 오류가 발생합니다.

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개
Reason: CORS request not HTTP
=============================

이유
--
```

Reason: CORS request not HTTP
```

무엇이 잘못되었는가?
-----------

CORS 요청은 오직 HTTPS URL 스키마만을 사용할 수 있지만 요청에 의해 지정된 URL은 다른 타입이다. 이는 URL이 `file:///` URL을 사용해 로컬 파일을 지정할 경우 종종 발생한다.

이 문제를 해결하려면, `XMLHttpRequest`, Fetch APIs, 웹 폰트 (`@font-face`), WebGL textures, XSL 스타일시트와 같은 CORS를 포함하는 요청이 발생할 때 HTTPS URL을 사용하고 있는지 확인하도록 한다.

### Firefox 68에서의 로컬 파일 보안

Firefox 67 이전 버전에서 `file:///` URI를 사용하는 페이지를 열때 페이지의 오리진은 페이지가 열린 디렉토리로 정의된다. 동일한 디렉토리와 그 하위 디렉토리의 리소스들은 CORS 동일-오리진 규칙의 목적을 위한 동일 오리진을 갖는 것으로 처리된다.

CVE-2019-11730에 대한 응답으로, Firefox 68 이후 버전에서는 `file:///` URI를 사용해 열린 페이지의 오리진은 유니크한 것으로 정의된다. 그러므로, 동일 디렉토리나 그 하위 디렉토리의 다른 리소스들은 더 이상 CORS 동일-오리진 규칙을 충족하지 않는다. 이는 `privacy.file_unique_origin` 구성을 사용하여 기본으로 활성화되는 새로운 동작이다.

함께 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개
* URL이 무엇인가?
Reason: CORS header 'Access-Control-Allow-Origin' missing
=========================================================

원인
--
```

원인 : CORS header 'Access-Control-Allow-Origin' missing
```

무엇이 문제인가요?
----------

CORS 요청에 대한 응답에 현재 오리진 내에서 작동하는 콘텐츠가 리소스에 액세스할 수 있는지 여부를 결정하는 데 사용되는 필수 `Access-Control-Allow-Origin` 헤더가 없습니다.

서버가 사용자의 제어 하에 있는 경우, 요청 사이트의 오리진을 `Access-Control-Allow-Origin` 헤더 값에 추가하여 액세스가 허용된 도메인 집합에 추가합니다.

예를 들어, `https://amazing.site` 사이트에 CORS를 사용하여 리소스에 액세스하려면 헤더는 다음과 같아야 합니다 :


```http
Access-Control-Allow-Origin: https://amazing.site
```


또한 `*` 와일드카드를 사용하여 모든 사이트에서 액세스할 수 있도록 사이트를 구성할 수도 있습니다. 공용 API에만 사용해야 합니다. 개인 API는 절대 `*`를 사용해서는 안 되며 대신 특정 도메인 또는 도메인이 설정되어 있어야 합니다. 또한 이 와일드카드는 `crossorigin` 속성이 `anonymous`로 설정된 요청에 대해서만 작동하며 요청에서 쿠키와 같은 자격 증명을 보내는 것을 방지합니다.


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


**경고:** 와일드카드를 사용하여 모든 사이트가 개인 API에 액세스할 수 있도록 허용하는 것은 좋지 않습니다.

 모든 사이트가 `*`를 사용하지 않고 CORS 요청을 수행할 수 있도록 하려면
 와일드카드(예: 자격 증명 사용)는 서버가 요청의 `Origin` 헤더 값을 읽고 해당 값을 사용하여 `Access-Control-Allow-Origin`을 설정해야 하며, 또한 일부 헤더가 오리진에 따라 동적으로 설정되고 있음을 나타내기 위해 `Vary: Origin` 헤더를 설정해야 합니다.

 헤더를 설정하는 정확한 명령문은 웹 서버에 따라 다릅니다. Apache에서 다음을 추가하십시오.
 Apache에서 다음과 같은 행을 서버의 구성에 추가합니다(해당하는 `<Directory>`, `<Location>`, `<Files>`, or `<VirtualHost>` 섹션 내). 구성은 일반적으로 `.conf` 파일(`httpd.conf`와 `apache.conf`와 같은 일반적인 이름) 또는 `.htaccess` 파일에 있습니다.
```

Header set Access-Control-Allow-Origin 'origin-list'
```


Nginx의 경우 이 헤더를 설정하는 명령은 다음과 같습니다 :
```

add_header 'Access-Control-Allow-Origin' 'origin-list';
```

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개
Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
=========================================================================

이유
--
```

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
```

무엇이 잘못되었나요?
-----------

서버에서 보낸 CORS 요청에 대한 응답에는 하나 이상의 잘못된 메서드 이름을 포함하는 `Access-Control-Allow-Methods` 헤더가 포함되어 있습니다.

`Access-Control-Allow-Methods` 헤더는 클라이언트가 CORS 요청에 대해 지원하는 HTTP 요청 메서드를 알리기 위해 서버에서 전송됩니다. 헤더의 값은 `GET`, `POST` 또는 `HEAD`와 같은 HTTP 메서드 이름들의 쉼표로 구분된 문자열입니다. 클라이언트 user agent에서 지정된 값을 인식하지 못하는 경우, 이 오류가 발생합니다.

이것은 `Access-Control-Allow-Methods` 헤더와 함께 유효하지 않거나 알 수 없는 메서드 이름을 더 이상 보내지 않도록 서버의 구성을 수정하여 서버 측에서만 해결할 수 있는 문제입니다. 클라이언트에서 사용 중인 사용자 에이전트 또는 HTTP 라이브러리가 최신인지 확인하는 것도 의미가 있습니다.

같이 보기
-----

* CORS 오류
* 용어 사전: CORS
* CORS 소개
* HTTP 요청 메서드
Reason: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '\*'
============================================================================================

원인
--
```

원인: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'
```

무엇이 문제인가요?
----------

자격 증명 플래그가 설정된 상태에서 CORS요청이 시도되었지만 서버는 자격 증명 사용을 허용하지 않는 `Access-Control-Allow-Origin`값으로 와일드카드(`"*"`)를 사용하여 구성됩니다.

클라이언트 측에서 이 문제를 해결하려면 CORS 요청을 발행할 때 자격 증명 플래그의 값이 `false`인지 확인하십시오.

* `XMLHttpRequest`를 사용하여 이슈가 발생하는 경우 `withCredentials` (en-US)를 `true`로 설정하지 않았는지 확인하십시오.
* Server-sent events를 사용하는 경우 `EventSource.withCredentials` (en-US)가 (기본값) `false`인지 확인하십시오.
* Fetch API를 사용하는 경우 `Request.credentials`가 `"omit"`인지 확인하십시오.

대신 서버의 동작을 조정해야 하는 경우 클라이언트가 로드되는 원본에 대한 액세스 권한을 부여하도록 `Access-Control-Allow-Origin`값을 변경해야 합니다.

같이 보기
-----

* CORS 에러
* Glossary: CORS
* CORS 소개
Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
=========================================================================

이유
--
```

Reason: invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
```

무엇이 문제인가요?
----------

서버에서 보낸 CORS 요청에 대한 응답에는 유효하지 않은 헤더 이름이 하나 이상 포함된 `Access-Control-Allow-Headers` 헤더가 포함되어 있습니다.

`Access-Control-Allow-Headers` 헤더는 preflight request에 대한 응답으로 서버에서 전송됩니다. 이를 통해 클라이언트는 CORS 요청에서 허용되는 HTTP headers를 알 수 있습니다. 클라이언트 user agent가 헤더에서 제공하는 쉼표로 구분된 값 중에서 인식하지 못하는 헤더 이름을 찾으면 오류가 발생합니다.

이것은 `Access-Control-Allow-Headers` 헤더와 함께 유효하지 않거나 알 수 없는 헤더 이름을 더 이상 보내지 않도록 서버 구성을 수정하여 서버 측에서만 수정할 수 있는 문제입니다. 클라이언트에서 사용 중인 사용자 에이전트 또는 HTTP 라이브러리가 최신인지 확인하는 것도 가치가 있을 수 있습니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 헤더
Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
======================================================================

원인
--
```

Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
```

무엇이 문제인가요?
----------

요청의 오리진이 헤더의 `Access-Control-Allow-Origin`에서 허용하고 있는 오리진의 내용과 일치하지 않습니다. 이 오류는 두 개 이상의 `Access-Control-Allow-Origin` 헤더를 응답에 포함하였을 때도 발생할 수 있습니다.

사용자의 제어 하에 작동하는 서비스에서 CORS 요청을 사용하는 경우, `Access-Control-Allow-Origin` 헤더에 사용자의 오리진이 포함되어 있는지 확인합니다. 또 하나의 헤더만이 응답에 포함되어 있는지, 응답에 하나의 오리진만 포함되어 있는지 확인합니다.

 예제로 Apache에서는 서버 설정 시 아래의 명령어를 추가합니다. (서버 설정은 `<Directory>`, `<Location>`, `<Files>`, 또는 `<VirtualHost>` 섹션 내부에 존재합니다.)
 설정은 일반적으로 `.conf` 파일(`httpd.conf`와 `apache.conf`가 일반적인 이름)이나 `.htaccess` 파일에서 찾을 수 있습니다.

**경고:** HTTPS 또는 HTTP 프로토콜에서 반드시 origin 항목을 포함하여야 합니다.
```

Header set Access-Control-Allow-Origin 'origin'
```


Ngix에서는 아래 명령어를 이용하여 헤더를 설정할 수 있습니다.
```

add_header 'Access-Control-Allow-Origin' 'origin'
```

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* CORS 사용: 내 서버에 CORS를 추가하고 싶다면
Reason: CORS request did not succeed
====================================

원인
--
```

원인: CORS 요청이 성공하지 못했습니다.
```

무엇이 문제인가요?
----------

네트워크 또는 프로토콜 수준에서 HTTP 연결이 실패했기 때문에 CORS를 사용하는 HTTP 요청이 실패했습니다. 이 에러는 근본적인 네트워크 에러이거나 그에 준하는 에러로 CORS와 직접적인 연관이 있는 것은 아닙니다.

더 보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개
Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
=====================================================================================================

이유
--
```

Reason: missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
```

무엇이 잘못되었나요?
-----------

`Access-Control-Allow-Headers` 헤더는 CORS 요청에 대해 지원하는 헤더를 알 수 있도록 서버에서 전송됩니다. `Access-Control-Allow-Headers` 값은 "`X-Custom-Information`" 또는 표준이지만 기본이 아닌 헤더 이름(항상 허용됩니다)과 같은 헤더 이름의 쉼표로 구분된 목록이어야 합니다.

이 오류는 명시적으로 허용되지 않은 헤더(즉, 서버에서 보낸 `Access-Control-Allow-Headers` 헤더에 지정된 목록에 포함되지 않는 경우에)를 사전 요청하려고 할 때 발생합니다. 이 문제를 해결하려면, 표시된 헤더를 허용하도록 서버를 갱신하거나, 해당 헤더를 사용하지 않도록 해야 합니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
* HTTP 헤더
Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
======================================================================

이유
--
```

Reason: Multiple CORS header 'Access-Control-Allow-Origin' not allowed
```

무엇이 잘못되었는가?
-----------

둘 이상의 `Access-Control-Allow-Origin` 헤더가 서버에서 전송되었습니다. 이것은 허용되지 않습니다.

서버에 접근할 수 있는 경우 `Access-Control-Allow-Origin` 헤더의 오리진을 다시 보낼 수 있도록 구현을 변경할 수 있습니다. 브라우저는 하나의 오리진 또는 null 값만 허용하므로 오리진 목록을 보낼 수 없습니다.

같이보기
----

* CORS 에러
* Glossary: CORS
* CORS 소개
* CORS 사용: 내 서버에 CORS를 추가하고 싶다면
Reason: CORS request external redirect not allowed
==================================================

이유
--
```

Reason: CORS request external redirect not allowed
```

무엇이 잘못되었나요?
-----------

CORS 요청이 CORS 요청 중에 허용되지 않는 원래 요청과 다른 출처의 URL에 대한 HTTP 리디렉션으로 서버에 의해 응답되었습니다.

예를 들어, `https://service.tld/fetchdata` 페이지가 요청되고, HTTP 응답은 "301 영구적으로 이동됨", "307 임시 리디렉션" 또는 "308 영구 리디렉션" 이고 `Location`이 `https://anotherservice.net/getdata`인 경우, 이러한 방식의 CORS 요청은 실패합니다.

문제를 해결하려면, 리디렉션에서 보고된 새 URL을 사용하도록 코드를 갱신하세요. 따라서 리디렉션을 피할 수 있습니다.

같이 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
=========================================================================

이유
--
```

Reason: expected 'true' in CORS header 'Access-Control-Allow-Credentials'
```

무엇이 문제인가요?
----------

CORS 요청은 서버가 자격 증명 사용을 허용하도록 요구하지만, 서버의 `Access-Control-Allow-Credentials` 헤더의 값이 `true`로 설정되지 않아 사용할 수 없습니다.

클라이언트 측에서 이 문제를 해결하려면, 자격 증명 사용을 요청하지 않도록 코드를 수정하세요.

* `XMLHttpRequest`를 통해서 요청을 생성하는 경우, `withCredentials` (en-US)를 `true`로 설정하지 않았는지 확인합니다.
* 서버 전송 이벤트를 사용하는 경우, `EventSource.withCredentials` (en-US)이 `false`인지 확인합니다(기본값입니다).
* Fetch API를 사용하는 경우, `Request.credentials` 가 `"omit"`인지 확인합니다.

서버의 구성을 변경하여 이 오류를 제거하려면, 서버의 `Access-Control-Allow-Credentials` 헤더 값을 `true`로 설정합니다.

함께 보기
-----

* CORS 에러
* 용어 사전: CORS
* CORS 소개
Reason: CORS preflight channel did not succeed
==============================================

원인
--
```

원인: CORS preflight 연결에 성공하지 못했습니다.
```

무엇이 문제인가요?
----------

CORS 요청에 preflight가 필요하며 preflight를 수행할 수 없습니다. preflight가 실패할 수 있는 몇 가지 이유가 있습니다.

* 이전에 이미 preflight를 수행한 교차 사이트 요청이 수행되었으며 preflight를 다시 수행하는 것은 허용되지 않습니다. 코드가 연결당 한 번씩만 preflight를 수행하는지 확인하십시오.
* 실행 전 요청에 일반적으로 발생할 수 있는 모든 종류의 네트워킹 오류가 발생했습니다.
더보기
---

* CORS 에러
* Glossary: CORS
* CORS 소개
431 Request Header Fields Too Large
===================================

HTTP **`431 Request Header Fields Too Large`** 응답 코드는 HTTP 헤더의 크기가 너무 크기 때문에 처리가 불가능함을 알려준다. 요청 헤더의 크기를 줄인 후, 재요청을 할 수 있다.

431는 헤더 전체의 크기가 너무 크거나, 단일 헤더 필드가 너무 클 경우에 사용된다. 이 에러를 받는 유저를 위해 응답 body에 둘 중에 어느 경우인지 명시해줄 수 있다 — 이상적으로, 어느 헤더가 처리 불가능한지 알려주면 좋다. 그러면 쿠키를 삭제하는 것과 같이 유저가 문제를 해결할 수 있도록 도와준다.

서버가 431 상태 코드를 전송할 경우:

* `Referer` URL이 너무 긴 경우
* 요청에 많은 양의 Cookies 포함된 경우
Status
------
```

431 Request Header Fields Too Large
```

명세서
---

| Specification |
| --- |
| RFC 6585 # section-5 |

See also
--------

* `414 URI Too Long`
* Request header
307 Temporary Redirect
======================

HTTP **`307 Temporary Redirect`** 리다이렉트 상태 응답 코드는 요청한 리소스가 `Location` (en-US) 헤더에 주어진 URL 로 임시로 옮겨졌다는 것을 나타냅니다.

원래 요청한 메소드와 Body 를 재사용하여 요청을 리다이렉트 합니다. 여기서 메소드를 `GET`으로 바꾸기 위해서 `303 See Other`를 사용하시면 됩니다. 이것은 `PUT`요청에 업로드된 리소스가 아닌 "You successfully uploaded XYZ"와 같은 확인메시지 응답을 제공 하는데에 유용합니다.

`307`과 `302`가 유일하게 다른점은 `307`은 Method 와 Body 를 변경하지 않고 리다이렉트 요청을 하도록 보장합니다. `302`응답으로 인하여 일부 오래된 클라이언트들은 메소드를 `GET`으로 틀리게 변경하였습니다. GET이 아닌 다른 메소드에 `302`동작은 웹에서 예상되지 않지만 `307` 동작은 예상할수 있습니다. GET 요청에 대해서는 동일하게 동작 합니다.

상태
--
```

307 Temporary Redirect
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.307 |

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

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

같이 보기
-----

* `302 Found`, the equivalent of this status code, but that may change the method used when it is not a `GET`.
* `303 See Other`, a temporary redirect that changes the method used to `GET`.
* `301 Moved Permanently`, a permanent redirect
400 Bad Request
===============

HyperText Transfer Protocol (HTTP) **`400 Bad Request`** 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.

**경고:** 클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.

Status
------
```

400 Bad Request
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.400 |
429 Too Many Requests
=====================

HTTP **`429 Too Many Requests`** 응답 상태 코드는 사용자가 주어진 시간 동안 너무 많은 요청을 보냈음을 나타냅니다("속도 제한").

새로운 요청을 하기 전에 얼마나 오래 대기해야 하는지를 알려주는 `Retry-After` 헤더가 이 응답에 포함될 수 있습니다.

상태
--
```

429 Too Many Requests
```

예제
--


```http
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
```

명세서
---

| Specification |
| --- |
| RFC 6585 # section-4 |

같이 보기
-----

* `Retry-After`
* HTTP/1.1: Status Code Definitions
* Python solution: How to avoid HTTP error 429 python
418 I'm a teapot
================

HTTP **`418 I'm a teapot`** 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 일시적으로 커피가 없는 커피/차 주전자는 대신 503을 반환해야 합니다. 이 오류는 1998년과 2014년 만우절 농담이었던 하이퍼 텍스트 커피 주전자 제어 규약(Hyper Text Coffee Pot Control Protocol)에 대한 참조입니다.

일부 웹사이트는 자동화된 쿼리와 같이 처리하고 싶지 않은 요청에 대해 이 응답을 사용합니다.

상태
--


```http
418 I'm a teapot
```

명세서
---

| Specification |
| --- |
| RFC 2324 # section-2.3.2 |

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

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

같이 보기
-----

* Wikipedia Hyper Text Coffee Pot Control Protocol
201 Created
===========

HTTP **`201 Created`** 는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다. 응답이 반환되기 이전에 새로운 리소스가 생성되며, 응답 메시지 본문에 새로 만들어진 리소스 혹은 리소스에 대한 설명과 링크를 메시지 본문에 넣어 반환합니다. 그 위치는 요청 URL 또는 `Location` (en-US) 헤더 값의 URL 입니다.

이 상태 코드의 일반적인 사용 사례는 `POST` 요청에 대한 결과입니다.

상태
--


```http
201 Created
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.201 |

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

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

같이 보기
-----

* HTTP request methods
404 Not Found
=============

 HTTP **`404 Not Found`** 클라이언트 오류 응답 코드는 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미합니다.
 404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 데드 링크(dead link)라고 부르며,
 link rot 대상일 수도 있습니다.

 404 상태 코드는 리소스가 일시적, 또는 영구적으로 사라졌다는 것을 의미하지는 않습니다. 리소스가 영구적으로 삭제되었다면
 404 상태 코드 대신 `410` (Gone) 상태 코드가 쓰여야 합니다.

상태
--


```http
404 Not Found
```

사용자 지정 에러 페이지
-------------

 많은 웹사이트들이 사용자에게 더 많은 도움을 주기 위해 404 페이지의 모습을 알맞게 재단합니다.
 예를 들어, 아파치 서버는 `.htaccess` 파일에 아래와 같은 코드를 작성해 설정할 수 있습니다.
```

ErrorDocument 404 /notfound.html
```


사용자 지정 404 페이지의 예시로는 404 page을 참고해보세요.

**참고:** 적당한 사용자 지정 디자인은 좋습니다. 404 페이지를 재밌게 만들되, 사용자를 혼란스럽게 하지는 마세요.

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.404 |

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

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

같이 보기
-----

* `410`
* HTTP\_404
303 See Other
=============

 HTTP(HyperText Transfer Protocol) **`303 See Other`** 리디렉션 상태 응답 코드는 리디렉션이 요청한
 리소스 자체에 연결되지 않고 다른 페이지(예: 확인 페이지, 실제 개체 표시(HTTP range-14 참조) 또는 업로드 진행률 페이지)에 연결됨을 나타냅니다.
 이 응답 코드는 `PUT` 또는 `POST`의 결과로 다시 전송되는 경우가 많습니다.
 이 리디렉션 페이지를 표시하는 데 사용되는 방법은 항상 `GET`입니다.

상태
--


```http
303 See Other
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.303 |

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

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

같이 보기
-----

* `302 Found`, a temporary redirect
* `307 Temporary Redirect`, 사용된 메서드가 절대 변경되지 않는 이
 상태 코드와 동일합니다.
205 Reset Content
=================

HTTP의 **`205 Reset Content`** 응답상태는 form의 내용을 지우거나, 캔버스 상태를 재설정하거나, UI를 새로 고치려면 client의 문서 화면 요소를 새로고침하라고 알려준다.

상태
--


```http
205 Reset Content
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.205 |

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

* 이 응답에 영속적인 연결의 본문이 잘못 포함된 경우 브라우저 동작이 달라집니다.
 자세한 내용은 204 No Content을 참조하세요.
같이 보기
-----

* `204` No Content
502 Bad Gateway
===============

하이퍼텍스트 전송 프로토콜(HTTP) **`502 Bad Gateway`** 에러 응답코드는 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받았다는 것을 의미합니다.

**참고:** Gateway 는 네트워킹에서 다른 것을 가르킬 수 있고 502 에러는 보통 여러분이 수정할 수 있는 것이 아니지만, 여러분이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.

상태
--


```http
502 Bad Gateway
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.502 |

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

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

같이 보기
-----

* `504`
* HTTP/1.1: Status Code Definitions
410 Gone
========

 하이퍼텍스트 전송 규약(HTTP) **`410 Gone`** 클라이언트 에러 응답 코드는 원본 서버에서 대상 리소스에 대해 더 이상 접근할 수
 없으며, 이 상태가 영구적일 가능성이 있음을 의미합니다.

이 상태가 일시적인지 영구적인지 알 수 없는 경우 `404` 상태 코드를 대신 사용해야 합니다.

**참고:** 410 응답은 기본적으로 캐시 가능합니다.

상태
--


```http
410 Gone
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.410 |

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

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

같이 보기
-----

* `404`
* 410 gone
408 Request Timeout
===================

HyperText Transfer Protocol (HTTP) **`408 Request Timeout`** 응답 상태 코드는 서버가 사용하지 않는 연결을 끊고 싶다는 것을 의미한다. 서버가 클라이언트의 요청 없이도 유휴 상태의 연결에 전송한다.

`408`은 서버가 계속해서 기다리기보다는 연결을 종료하기로 결정했다는 것을 알려주기 때문에, 서버는 응답에 "close" `Connection`헤더 필드를 추가해서 전송해야한다.

크롬, Firefox 27+, 그리고 인터넷 익스플로러 9와 같은 브라우저들이 서핑 속도를 높이기 위해 HTTP pre-connection 방식을 사용하기 때문에 이 응답이 더 많이 사용되고 있다.

**참고:** **Note: 어떤 서버들은 이 메세지를 전송하지 않고 연결을 종료할 수도 있다**.

Status
------
```

408 요청 시간 만료
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.408 |

See also
--------

* `Connection`
* `X-DNS-Prefetch-Control` (en-US)
103 Early Hints
===============

**실험적:** **이 기능은 실험적인 기능입니다.**  
프로덕션 환경에서 사용하기 전에 브라우저 호환성 표를 주의 깊게 확인하세요.

 HTTP **`103 Early Hints`** 정보 상태 응답 코드는 서버가 응답을 준비하는 동안에도 사용자 에이전트가
 리소스를 미리읽어들일 수 있도록, 주로 `Link` (en-US) 헤더와 함께 사용됩니다.

상태
--


```http
103 Early Hints
```

명세서
---

| Specification |
| --- |
| An HTTP Status Code for Indicating Hints # section-2 |
| HTML Standard # early-hints |

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

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

같이 보기
-----

* `Link` (en-US)
414 URI Too Long
================

HTTP **`414 URI Too Long`** 응답 코드는 클라이언트가 요청한 URI가 서버가 해석가능한 URI보다 더 길다는 것을 나타냅니다.

이 문제가 발생할 수 있는 몇 가지 보기 드문 상황이 있습니다.

* 클라이언트가 `POST` 요청을 부적절하게 긴 쿼리 정보를 가진 `GET` 요청으로 변환한 경우
* 클라이언트가 리디렉션 루프(예: 자신의 접미사를 가리키는 리디렉션된 URI 접두사)에 빠진 경우
* 또는 서버의 잠재적인 보안 허점을 악용하려는 클라이언트의 공격을 받는 경우
상태
--
```

414 URI Too Long
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.414 |

같이 보기
-----

* URI
425 Too Early
=============

하이퍼텍스트 전송 프로토콜(HTTP) **`425 Too Early`** 응답 상태 코드는 서버가 재전송 될 수 있는 요청을 처리하는 데 위험을 감수하기를 원하지 않으며, 이는 재전송 공격(replay attack)의 가능성을 만들 수 있다는 것을 나타냅니다.

상태
--


```http
425 Too Early
```

명세서
---

| Specification |
| --- |
| Using Early Data in HTTP # status |

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

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
411 Length Required
===================

 하이퍼텍스트 전송 규약(HTTP) **`411 Length Required`** 클라이언트 오류 응답 코드는 서버가 정의된
 `Content-Length` 헤더 없이 요청을 수락하지 않음을 나타냅니다.


**참고:** 사양에 따라 데이터를 일련의 큰 덩어리(chunk) 단위로 데이터를 전송할 때 `Content-Length` 헤더가 생략되며,
 각 청크의 시작 부분에서 현재 청크의 길이를 16진수 형식으로 추가해야 합니다. 자세한 내용은
 `Transfer-Encoding`을 참조하십시요.


상태
--


```http
411 Length Required
```

정의
--

| Specification |
| --- |
| HTTP Semantics # status.411 |

참고
--

* `Content-Length`
* `Transfer-Encoding`
409 Conflict
============

HTTP **`409 Conflict`** 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타냅니다.

 충돌은 `PUT` 요청에 대응하여 발생할 가능성이 가장 높습니다. 예를 들어 서버에 이미 있는 파일보다 오래된 파일을
 업로드하면 버전 제어 충돌이 발생하여 409 응답받을 수 있습니다.

상태
--


```http
409 Conflict
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.409 |

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

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

같이 보기
-----

* `PUT`
415 Unsupported Media Type
==========================

HTTP **'415 지원되지 않는 미디어 유형'** 클라이언트 오류 응답 코드는 클라이언트가 보낸 페이로드가 지원하지 않는 형식이기 때문에 서버가 요청을 수락하지 않음을 나타냅니다.

형식 문제는 요청에 표시된 `Content-Type` 또는 `Content-Encoding`으로 인해 발생하거나 데이터를 직접 검사한 결과 발생할 수 있습니다.

상태
--
```

415 Unsupported Media Type
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.415 |

같이 보기
-----

* `Content-Type`
* `Content-Encoding`
* `Accept`
424 Failed Dependency
=====================

하이퍼텍스트 전송 프로토콜(HTTP) **`424 Failed Dependency`** 응답 상태 코드는 요청한 동작이 다른 동작에 의존하며 해당 동작이 실패한 경우에 해당 리소스에서 메서드를 수행할 수 없음을 나타냅니다.

보통 일반 웹 서버에서는 이 상태 코드를 반환하지 않습니다. 하지만 WebDAV와 같은 일부 다른 프로토콜에서는 이 코드를 반환할 수 있습니다. 예를 들어, WebDAV에서 `PROPPATCH` 요청을 보냈을 때 하나의 명령이 실패하면 자동으로 다른 모든 명령도 `424 Failed Dependency`로 실패합니다.

상태
--

| Specification |
| --- |
| RFC 4918 # section-11.4 |

같이 보기
-----

* `403` (Forbidden)
401 Unauthorized
================

 HTTP(하이퍼텍스트 전송 프로토콜) **`401 Unauthorized`** 응답 상태 코드는 요청된 리소스에 대한
 유효한 인증 자격 증명이 없기 때문에 클라이언트 요청이 완료되지 않았음을 나타냅니다.

 이 상태 코드는 사용자에게 인증 자격 증명을 입력하라는 메시지를 표시한 후 클라이언트가 리소스를 다시 요청할 수 있는
 방법이 포함된 HTTP `WWW-Authenticate` (en-US) 응답 헤더와 함께 전송됩니다.

 이 상태 코드는 `403 Forbidden` 상태 코드와 유사합니다.
 다만 이 상태 코드가 발생하는 상황에서 사용자 인증을 통해 리소스에 대한 액세스를 허용할 수 있습니다.

상태
--


```http
401 Unauthorized
```

응답 예시
-----


```http
HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.401 |

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

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

같이 보기
-----

* HTTP 인증
* `WWW-Authenticate` (en-US)
* `Authorization`
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `403`, `407` (en-US)
200 OK
======

HTTP **`200 OK`** 는 요청이 성공했음을 나타내는 성공 응답 상태 코드입니다. 200 응답은 기본적으로 캐시 가능합니다.

성공의 의미는 다음과 같이 HTTP 요청 메서드에 따라 나뉩니다.

* `GET`: 리소스를 가져왔고 메시지 본문으로 전송되었다는 것을 의미합니다.
* `HEAD`: 메시지 본문 없이 표현 헤더가 응답에 포함되어 있다는 것을 의미합니다.
* `POST`: 리소스가 명시하는 행동의 결과가 메시지 본문에 전송되었다는 것을 의미합니다.
* `TRACE` (en-US): 서버가 요청받은 메시지가 메시지 본문에 포함되어 있다는 것을 의미합니다.

`PUT` 또는 `DELETE`의 성공 결과는 종종 `200 OK`가 아니라 `204` `No Content`(리소스를 새로 생성한 경우 `201` `Created` 입니다).

상태
--


```http
200 OK
```

명세
--

| Specification |
| --- |
| HTTP Semantics # status.200 |

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

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

같이 보기
-----

* HTTP 요청 메서드
405 Method Not Allowed
======================

 하이퍼텍스트 전송 프로토콜(HTTP)의 **`405 Method Not Allowed`** 응답 상태 코드는 서버가 요청 메서드를 알고 있지만
 대상 리소스가 이 메서드를 지원하지 않음을 가리킵니다.

 서버는 405 코드를 응답할 경우 **반드시** **`Allow`** 헤더 필드를 생성해야 합니다. 이 필드에는 반드시 현재 대상 리소스에서
 지원하는 메서드의 리스트가 들어있어야 합니다.

상태
--


```http
405 Method Not Allowed
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.405 |

같이 보기
-----

* `Allow`
* HTTP/1.1: Status Code Definitions
* How to Fix 405 Method Not Allowed
* Troubleshooting HTTP 405
 Footer
302 Found
=========

 HTTP(HyperText Transfer Protocol) **`302 Found`** 리디렉션 상태 응답 코드는 요청한 리소스가
 `Location` (en-US) 헤더에 지정된 URL로 일시적으로 이동되었음을 나타냅니다. 브라우저는 이 페이지로
 리디렉션되지만 검색 엔진은 리소스에 대한 링크를 업데이트하지 않습니다('SEO-speak'에서는 'link-juice'가 새
 URL로 전송되지 않는다고 합니다).

 명세서에서 리디렉션이 수행될 때 메서드(및 본문)가 변경되지 않도록 요구하더라도 모든 사용자 에이전트가 이를 준수하는
 것은 아닙니다. 여러분은 여전히 이러한 유형의 버그가 있는 소프트웨어를 찾을 수 있습니다. 따라서 따라서 `302` 코드는
 `GET` 또는 `HEAD` 메서드에 대한 응답으로만 설정하고 이 경우 메서드
 변경이 명시적으로 금지되므로 `307 Temporary Redirect` 를 대신 사용하는 것이
 좋습니다.

 사용하던 메서드를 `GET`으로 변경하려는 경우,
 `303 See Other`을 대신 사용하십시오.
 `PUT` 메서드에 대한 응답을 업로드된 리소스가 아니라 'You successfully updown XYZ'와
 같은 확인 메시지로 주고 싶을때 유용합니다.

상태
--


```http
302 Found
```

명세서
---

| Specification |
| --- |
| HTTP Semantics # status.302 |

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

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

같이 보기
-----

* `307 Temporary Redirect`, 사용된 메서드가 절대 변경되지 않는 이 상태 코드와 동일합니다.
* `303 See Other`, `GET`에 사용되는 메서드를 변경하는 임시 리디렉션입니다.
* `301 Moved Permanently`, 영구 리다이렉션