- Published on
HTTP 응답 상태 코드
- Authors
- Name
- Charles
한국어로 번역된 내용 및 한국어 버전이 없는 내용은 DeepL로 번역하여 추가하였습니다.
100 Continue
HTTP 100 Continue 정보 상태 응답 코드는 클라이언트가 서버로 보낸 요청에 문제가 없으니 다음 요청을 이어서 보내도 된다는 것을 의미한다. 만약 클라이언트의 작업이 완료되었다면 이 응답은 무시해도 된다.
클라이언트가 서버로 하여금 이를 검토하게 하려면 첫 번째 요청에서 Expect: 100-continue 를 헤더로 보내야한다. 이후, 클라이언트는 본문을 보내기 전에 서버가 100 Continue 상태 코드로 응답하길 기다려야 한다.
101 Switching Protocols
HTTP 101 Switching Protocols 응답 코드는 서버가 전환되는 프로토콜을 가리킨다. 프로토콜은 클라이언트로부터 받은 Upgrade (en-US) 헤더에 명시되어 있다.
서버는 이 응답에 전환된 프로토콜을 나타내는 Upgrade (en-US) 헤더를 포함한다. 이 절차는 프로토콜 업그레이드 메커니즘 (en-US) 문서에 설명되어 있다.
102 Processing(Deprecated)
103 Early Hints
HTTP 103 Early Hints 정보 응답은 서버가 응답을 준비하는 동안 서버가 최종 응답에 연결할 것으로 예상되는 사이트 및 리소스에 대한 힌트와 함께 전송될 수 있습니다. 이를 통해 브라우저는 서버가 최종 응답을 준비하여 전송하기 전에도 사이트에 미리 연결하거나 리소스 사전 로딩을 시작할 수 있습니다.
초기 힌트 응답은 주로 로드할 리소스를 나타내는 링크 헤더와 함께 사용하기 위한 것입니다. 또한 초기 힌트를 처리하는 동안 적용되는 Content-Security-Policy 헤더를 포함할 수도 있습니다.
예를 들어 서버는 리디렉션 후 여러 개의 103 응답을 보낼 수 있습니다. 브라우저는 첫 번째 초기 힌트 응답만 처리하며, 요청으로 인해 교차 출처 리디렉션이 발생하는 경우 이 응답은 폐기해야 합니다. 초기 힌트에서 미리 로드된 리소스는 문서의 헤드 요소에 효과적으로 미리 붙여진 다음 최종 응답에 로드된 리소스가 뒤따릅니다.
200 OK
HTTP 200 OK 는 요청이 성공했음을 나타내는 성공 응답 상태 코드입니다. 200 응답은 기본적으로 캐시 가능합니다.
성공의 의미는 다음과 같이 HTTP 요청 메서드에 따라 나뉩니다.
GET: 리소스를 가져왔고 메시지 본문으로 전송되었다는 것을 의미합니다.HEAD: 메시지 본문 없이 표현 헤더가 응답에 포함되어 있다는 것을 의미합니다.POST: 리소스가 명시하는 행동의 결과가 메시지 본문에 전송되었다는 것을 의미합니다.TRACE(en-US): 서버가 요청받은 메시지가 메시지 본문에 포함되어 있다는 것을 의미합니다.
PUT 또는 DELETE의 성공 결과는 종종 200 OK 가 아니라 204 No Content (리소스를 새로 생성한 경우 201 Created 입니다).
201 Created
HTTP 201 Created 는 요청이 성공적으로 처리되었으며, 자원이 생성되었음을 나타내는 성공 상태 응답 코드입니다. 응답이 반환되기 이전에 새로운 리소스가 생성되며, 응답 메시지 본문에 새로 만들어진 리소스 혹은 리소스에 대한 설명과 링크를 메시지 본문에 넣어 반환합니다. 그 위치는 요청 URL 또는 Location (en-US) 헤더 값의 URL 입니다.
202 Accepted
하이퍼텍스트 전송 프로토콜 (HTTP) 202 Accepted 는 요청이 처리를 위해 수락되었으나, 아직 해당 요청에 대해 처리 중이거나 처리가 시작되지 않았을 수 있다는 것을 의미합니다. 요청이 처리 중 실패할 수도 있기 때문에 요청은 실행될 수도 실행되지 않을수도 있습니다.
이 상태 코드는 모호합니다. 즉 HTTP가 나중에 요청 처리 결과를 나타내는 비동기 응답을 보낼 방법이 없다는 것을 의미합니다. 이는 다른 프로세스나 서버가 요청을 처리하는 경우 또는 일괄 처리를 위한 것입니다.
203 Non-Authoritative Information
The HTTP 203 Non-Authoritative Information 는 요청이 성공했지만 오리진 서버의 200 (OK) 응답에서 proxy에 의해 포함된 페이로드가 수정되었음을 나타냅니다.
203 응답은 Warning (en-US) 헤더 코드의 변환 적용을 의미하는 214 (en-US) 값과 유사하며, 모든 상태 코드가 있는 응답에 적용할 수 있다는 추가적인 이점이 있습니다.
204 No Content
HTTP 204 No Content 성공 상태 응답 코드는 요청이 성공했으나 클라이언트가 현재 페이지에서 벗어나지 않아도 된다는 것을 나타냅니다.
예를 들어, 위키 사이트에 "저장 후 편집 계속" 기능을 구현할 때 사용할 수 있습니다. 이 경우 PUT 요청을 사용하여 페이지를 저장하고 204 No Content 응답을 전송하여 편집기를 다른 페이지로 대체해서는 안 된다는 것을 나타냅니다.
204 응답은 기본적으로 캐시 가능하며, 캐시에서 가져온 응답인 경우 ETag 헤더를 포함합니다.
205 Reset Content
HTTP의 205 Reset Content 응답상태는 form의 내용을 지우거나, 캔버스 상태를 재설정하거나, UI를 새로 고치려면 client의 문서 화면 요소를 새로고침하라고 알려준다.
206 Partial Content
HTTP 206 Partial Content 는 Range 헤더에 기술된 데이터 범위에 대한 요청이 성공적으로 응답되어 본문에 해당되는 데이터를 담고 있다는 것을 알려줍니다.
만약 단일 범위 요청을 한 경우엔, 전체 응답의 Content-Type은 문서 타입으로 설정되며, Content-Range가 제공됩니다.
만약 다중 범위 요청에 대한 응답이라면, Content-Type는 multipart/byteranges로 되며 분할된 데이터의 응답은 Content-Range와 Content-Type로 각각의 범위를 기술합니다.
207 Multi-Status
리소스 컬렉션을 반환하는 기능은 WebDAV 프로토콜의 일부입니다(WebDAV 서버에 액세스하는 웹 애플리케이션에서 수신할 수 있음). 웹 페이지에 액세스하는 브라우저에는 이 상태 코드가 표시되지 않습니다.
HTTP 207 Multi-Status 응답 코드는 응답이 혼합되어 있을 수 있음을 나타냅니다.
응답 본문은 multistatus 루트 요소가 있는 text/xml 또는 application/xml HTTP 엔티티입니다. XML 본문에는 모든 개별 응답 코드가 나열됩니다.
208 Already Reported
리소스 컬렉션을 반환하는 기능은 WebDAV 프로토콜의 일부입니다(WebDAV 서버에 액세스하는 웹 애플리케이션에서 수신할 수 있음). 웹 페이지에 액세스하는 브라우저에는 이 상태 코드가 표시되지 않습니다.
HTTP 208 Already Reported 응답 코드는 공간을 절약하고 충돌을 피하기 위해 207 (207 Multi-Status 응답에 사용됩니다. 동일한 리소스를 여러 번(예: 컬렉션의 일부로) 다른 경로로 요청하는 경우 첫 번째 리소스만 200으로 보고됩니다. 다른 모든 바인딩에 대한 응답은 이 208 상태 코드로 보고되므로 충돌이 발생하지 않고 응답이 더 짧게 유지됩니다.
226 IM Used
브라우저는 HTTP에서 델타 인코딩을 지원하지 않습니다. 이 상태 코드는 특정 클라이언트에서 사용하는 사용자 정의 서버에서 다시 전송됩니다.
델타 인코딩의 맥락에서 HTTP 226 IM Used 상태 코드는 서버가 수신한 GET 요청에 델타를 반환하고 있음을 나타내기 위해 설정됩니다.
델타 인코딩을 사용하면 서버는 현재 문서가 아닌 지정된 기본 문서를 기준으로 차이(델타라고 함)가 있는 GET 요청에 응답합니다. 클라이언트는 A-IM: HTTP 헤더를 사용하여 사용할 차이 알고리즘을 표시하고 If-None-Match: 헤더를 사용하여 서버가 마지막으로 받은 버전에 대한 힌트를 서버에 제공합니다. 서버는 델타를 생성하여 226 상태 코드와 함께 IM:(사용된 알고리즘의 이름 포함) 및 Delta-Base:(델타와 연결된 기본 문서와 일치하는 ETag 포함) HTTP 헤더를 포함하는 HTTP 응답으로 다시 보냅니다.
IM은 델타를 생성하는 알고리즘을 설명하는 데 사용되는 용어인 인스턴스 조작을 나타냅니다.
300 Multiple Choices
HTTP 300 Multiple Choices 리디렉션 상태 응답 코드는 요청에 가능한 응답이 두 개 이상 있음을 의미합니다. 사용자 에이전트 또는 사용자는 둘 중 하나를 선택해야 합니다. 응답 중 하나를 선택하는 표준화된 방법이 없기 때문에 이 응답 코드는 거의 사용되지 않습니다.
서버는 선호하는 선택 항목이 있는 경우, Location (en-US)를 생성해야 합니다.
301 Moved Permanently
HTTP 301 Moved Permanently 리디렉션 상태 응답 코드는 요청한 리소스가 Location (en-US) 헤더에 주어진 URL로 완전히 옮겨졌다는 것을 나타냅니다. 브라우저는 이 페이지로 리디렉트하고, 검색 엔진은 해당 리소스로 연결되는 링크를 갱신합니다.
명세에서는 리디렉션를 수행할 때 메서드와 본문이 변경되지 않아야 한다고 하지만, 모든 사용자 에이전트가 이 요구사항을 충족하지 않습니다.
301코드는GET과HEAD메서드의 응답으로만 사용하고,POST메서드에 대해서는 메서드 변경이 명시적으로 금지된308 Permanent Redirect사용이 바람직합니다.
302 Found
HTTP 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'와 같은 확인 메시지로 주고 싶을때 유용합니다.
303 See Other
HTTP 303 See Other 리디렉션 상태 응답 코드는 리디렉션이 요청한 리소스 자체에 연결되지 않고 다른 페이지(예: 확인 페이지, 실제 개체 표시(HTTP range-14 참조) 또는 업로드 진행률 페이지)에 연결됨을 나타냅니다. 이 응답 코드는 PUT 또는 POST의 결과로 다시 전송되는 경우가 많습니다. 이 리디렉션 페이지를 표시하는 데 사용되는 방법은 항상 GET입니다.
304 Not Modified
클라이언트 리디렉션 응답 코드 304 Not Modified 는 요청된 리소스를 재전송할 필요가 없음을 나타낸다. 캐시된 자원으로의 암묵적인 리디렉션이다. 이는 GET 나 HEAD 요청처럼 요청 방법이 안전한 경우 또는 요청이 조건부로 If-None-Match 또는 If-Modified-Since 헤더를 사용할 때 응답 된다.
이에 상응하는 200 OK 응답에는 Cache-Control, Content-Location, Date, ETag, Expires, 그리고 Vary 가 포함되어 있었을 것이다.
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 요청에 대해서는 동일하게 동작 합니다.
308 Permanent Redirect
HTTP 308 Permanent Redirect 리디렉션 상태 응답 코드는 요청된 리소스가 Location (en-US) 헤더에 지정된 URL로 확실히 이동되었음을 나타냅니다. 브라우저가 이 페이지로 리디렉션되고 검색엔진은 리소스에 대한 링크를 업데이트합니다('SEO-speak'에서는 'link-juice'가 새 URL로 전송됩니다).
요청 메서드와 본문은 변경되지 않지만, 301은 때때로 GET 메서드로 잘못 변경될 수 있습니다.
일부 웹 응용 프로그램은
308 Permanent Redirect를 비표준 방식 및 기타 목적으로 사용합니다. 예를 들어, Google Drive는308 Resume Incomplete응답을 사용하여 불완전한 업로드가 중단된 경우 클라이언트에 알립니다(Google Drive 문서의 다시 시작할 수 있는 다운로드 수행을 참조하세요).
400 Bad Request
HTTP 400 Bad Request 응답 상태 코드는 서버가 클라이언트 오류(예: 잘못된 요청 구문, 유효하지 않은 요청 메시지 프레이밍, 또는 변조된 요청 라우팅) 를 감지해 요청을 처리할 수 없거나, 하지 않는다는 것을 의미합니다.
클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.
401 Unauthorized
HTTP 401 Unauthorized 응답 상태 코드는 요청된 리소스에 대한 유효한 인증 자격 증명이 없기 때문에 클라이언트 요청이 완료되지 않았음을 나타냅니다.
이 상태 코드는 사용자에게 인증 자격 증명을 입력하라는 메시지를 표시한 후 클라이언트가 리소스를 다시 요청할 수 있는 방법이 포함된 HTTP WWW-Authenticate (en-US) 응답 헤더와 함께 전송됩니다.
이 상태 코드는 403 Forbidden 상태 코드와 유사합니다. 다만 이 상태 코드가 발생하는 상황에서 사용자 인증을 통해 리소스에 대한 액세스를 허용할 수 있습니다.
402 Payment Required
실험적: 실험 중인 기술입니다.
프로덕션 환경에서 사용하기 전에 브라우저 호환성 표를 주의 깊게 확인하세요.
HTTP 402 Payment Required 는 향후 사용을 위해 예약된 비표준 응답 상태 코드입니다. 이 상태 코드는 디지털 현금 또는 (소액) 결제 시스템을 활성화하기 위해 만들어졌으며, 클라이언트가 결제할 때까지 요청된 콘텐츠를 사용할 수 없음을 나타냅니다.
때때로 이 상태 코드는 클라이언트가 결제할 때까지 요청을 처리할 수 없음을 나타냅니다. 그러나 표준 사용 규칙은 존재하지 않으며 여러 기관에서 각기 다른 맥락에서 이 코드를 사용합니다.
403 Forbidden
HTTP 403 Forbidden 클라이언트 오류 상태 응답 코드는 서버에 요청이 전달되었지만, 권한 때문에 거절되었다는 것을 의미합니다.
이 상태는 401과 비슷하지만, 로그인 로직(틀린 비밀번호로 로그인 행위)처럼 반응하여 재인증(re-authenticating)을 하더라도 지속적으로 접속을 거절합니다.
404 Not Found
HTTP 404 Not Found 클라이언트 오류 응답 코드는 서버가 요청받은 리소스를 찾을 수 없다는 것을 의미합니다. 404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 데드 링크(dead link)라고 부르며, link rot 대상일 수도 있습니다.
404 상태 코드는 리소스가 일시적, 또는 영구적으로 사라졌다는 것을 의미하지는 않습니다. 리소스가 영구적으로 삭제되었다면 404 상태 코드 대신 410 (Gone) 상태 코드가 쓰여야 합니다.
405 Method Not Allowed
HTTP 405 Method Not Allowed 응답 상태 코드는 서버가 요청 메서드를 알고 있지만 대상 리소스가 이 메서드를 지원하지 않음을 가리킵니다.
서버는 405 코드를 응답할 경우 반드시 Allow 헤더 필드를 생성해야 합니다. 이 필드에는 반드시 현재 대상 리소스에서 지원하는 메서드의 리스트가 들어있어야 합니다.
406 Not Acceptable
HTTP 406 Not Acceptable 클라이언트 에러 응답 코드는 서버가 요청의 주도적인 콘텐츠 협상 헤더에 정의된 허용 가능한 값 목록과 일치하는 응답을 생성할 수 없으며, 서버가 기본 표현을 제공하지 않음을 나타냅니다.
주도적인 콘텐츠 협상 헤더는 다음과 같습니다.
실제로 이 오류가 사용되는 경우는 거의 드뭅니다. 서버는 최종 사용자에게 이런 비밀스럽고 수정하기 어려운 오류 코드로 응답하는 대신, 관련 헤더를 무시하고 사용자에게 실제 페이지를 제공합니다. 사용자가 이 결과에 완벽하게 만족하진 않더라도, 에러 코드보다는 선호할 것입니다.
서버가 이러한 오류 상태를 반환하는 경우, 메시지 본문에는 사용 가능한 리소스 표현 목록이 포함되어야 하며, 사용자가 그 중에서 선택할 수 있어야 합니다.
407 Proxy Authentication Required
HTTP 407 Proxy Authentication Required 클라이언트 오류 상태 응답 코드는 브라우저와 요청된 리소스에 액세스할 수 있는 서버 사이에 있는 proxy server에 대한 유효한 인증 자격 증명이 없기 때문에 요청이 적용되지 않았음을 나타냅니다.
이 상태는 올바른 인증 방법에 대한 정보가 포함된 Proxy-Authenticate 헤더와 함께 전송됩니다.
408 Request Timeout
HTTP 408 Request Timeout 응답 상태 코드는 서버가 사용하지 않는 연결을 끊고 싶다는 것을 의미한다. 서버가 클라이언트의 요청 없이도 유효 상태의 연결에 전송한다.
408은 서버가 계속해서 기다리기보다는 연결을 종료하기로 결정했다는 것을 알려주기 때문에, 서버는 응답에 "close" Connection헤더 필드를 추가해서 전송해야한다.
크롬, Firefox 27+, 그리고 인터넷 익스플로러 9와 같은 브라우저들이 서핑 속도를 높이기 위해 HTTP pre-connection 방식을 사용하기 때문에 이 응답이 더 많이 사용되고 있다.
어떤 서버들은 이 메세지를 전송하지 않고 연결을 종료할 수도 있다.
409 Conflict
HTTP 409 Conflict 응답 상태 코드는 서버의 현재 상태와 요청이 충돌했음을 나타냅니다.
충돌은 PUT 요청에 대응하여 발생할 가능성이 가장 높습니다. 예를 들어 서버에 이미 있는 파일보다 오래된 파일을 업로드하면 버전 제어 충돌이 발생하여 409 응답받을 수 있습니다.
410 Gone
HTTP 410 Gone 클라이언트 에러 응답 코드는 원본 서버에서 대상 리소스에 대해 더 이상 접근할 수 없으며, 이 상태가 영구적일 가능성이 있음을 의미합니다.
이 상태가 일시적인지 영구적인지 알 수 없는 경우 404 상태 코드를 대신 사용해야 합니다.
411 Length Required
HTTP 411 Length Required 클라이언트 오류 응답 코드는 서버가 정의된 Content-Length 헤더 없이 요청을 수락하지 않음을 나타냅니다.
사양에 따라 데이터를 일련의 큰 덩어리(chunk) 단위로 데이터를 전송할 때
Content-Length헤더가 생략되며, 각 청크의 시작 부분에서 현재 청크의 길이를 16진수 형식으로 추가해야 합니다. 자세한 내용은Transfer-Encoding을 참조하십시요.
412 Precondition Failed
HTTP 412 Precondition Failed 클라이언트 오류 응답 코드는 대상 리소스에 대한 액세스가 거부되었음을 나타냅니다. 이는 GET 또는 HEAD 이외의 메서드에 대한 조건부 요청에서 If-Unmodified-Since 또는 If-None-Match 헤더에 정의된 조건이 충족되지 않을 때 발생합니다. 이 경우 일반적으로 리소스의 업로드 또는 수정과 같은 요청을 수행할 수 없으며 이 오류 응답이 다시 전송됩니다.
413 Content Too Large
HTTP 413 Content Too Large 응답 상태 코드는 요청 엔터티가 서버에 의해 정의된 제한보다 크다는 것을 나타냅니다. 서버는 연결을 닫거나 Retry-After 헤더 필드를 반환할 수 있습니다.
RFC 9110 이전에는 이 상태 코드 이름이 Payload Too Large 였습니다. 이 이름은 아직도 널리 사용되고 있습니다.
414 URI Too Long
HTTP 414 URI Too Long 응답 코드는 클라이언트가 요청한 URI가 서버가 해석가능한 URI보다 더 길다는 것을 나타냅니다.
이 문제가 발생할 수 있는 몇 가지 보기 드문 상황이 있습니다.
- 클라이언트가
POST요청을 부적절하게 긴 쿼리 정보를 가진GET요청으로 변환한 경우 - 클라이언트가 리디렉션 루프(예: 자신의 접미사를 가리키는 리디렉션된 URI 접두사)에 빠진 경우
- 또는 서버의 잠재적인 보안 허점을 악용하려는 클라이언트의 공격을 받는 경우
415 Unsupported Media Type
HTTP 415 Unsupported Media Type 클라이언트 오류 응답 코드는 클라이언트가 보낸 페이로드가 지원하지 않는 형식이기 때문에 서버가 요청을 수락하지 않음을 나타냅니다.
형식 문제는 요청에 표시된 Content-Type 또는 Content-Encoding으로 인해 발생하거나 데이터를 직접 검사한 결과 발생할 수 있습니다.
416 Range Not Satisfiable
HTTP 416 Range Not Satisfiable 에러 응답 코드는 서버가 요청받은 범위에 대해서 서비스 할 수 없음을 알려줍니다. 아마도 이유는 그 문서가 그러한 범위를 지니고 있지 않거나, 또는 Range 헤더 값이 문법적으로는 옳지만, 이해가 되지 않을 경우 그럴 수 있습니다.
416 응답 메시지는 Content-Range 를 포함하여 만족할 수 없는 범위(그 경우 '*') 뒤에 '/'와 현재 리소스를 알려줍니다. 예: Content-Range: */12777
이 에러를 마주하면, 브라우저는 보통 명령을 취소하거나 전체 문서를 다시 요청합니다.
417 Expectation Failed
HTTP 417 Expectation Failed 클라이언트 오류 응답 코드는 요청의 Expect 헤더에 지정된 기대치를 충족할 수 없음을 나타냅니다.
418 I'm a teapot
HTTP 418 I'm a teapot 클라이언트 오류 응답 코드는 서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다. 일시적으로 커피가 없는 커피/차 주전자는 대신 503을 반환해야 합니다. 이 오류는 1998년과 2014년 만우절 농담이었던 하이퍼 텍스트 커피 주전자 제어 규약(Hyper Text Coffee Pot Control Protocol)에 대한 참조입니다.
일부 웹사이트는 자동화된 쿼리와 같이 처리하고 싶지 않은 요청에 대해 이 응답을 사용합니다.
421 Misdirected Request
HTTP 421 Misdirected Request 클라이언트 오류 응답 코드는 요청이 응답을 생성할 수 없는 서버로 전달되었음을 나타냅니다. 연결이 재사용되었거나 대체 서비스를 선택한 경우 이 오류가 발생할 수 있습니다.
422 Unprocessable Content
하이퍼텍스트 전송 프로토콜(HTTP) 422 Unprocessable Content 응답 상태 코드는 서버가 요청 엔티티의 컨텐츠 형식을 이해했고 요청 엔티티의 문법도 올바르지만 요청된 지시를 처리할 수 없음을 나타냅니다.
클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안됩니다.
423 Locked
리소스를 잠그는 기능은 일부 WebDAV 서버에 한정되어 있습니다. 웹 페이지에 액세스하는 브라우저에는 이 상태 코드가 표시되지 않으며, 잘못 표시되는 경우 일반
400상태 코드로 처리합니다.
HTTP 423 Locked 오류 응답 코드는 잠정적으로 타겟팅한 리소스가 잠겨 있어 액세스할 수 없음을 나타냅니다. 해당 콘텐츠에는 WebDAV의 XML 형식의 일부 정보가 포함되어 있어야 합니다.
424 Failed Dependency
HTTP 424 Failed Dependency 응답 상태 코드는 요청한 동작이 다른 동작에 의존하며 해당 동작이 실패한 경우에 해당 리소스에서 메서드를 수행할 수 없음을 나타냅니다.
보통 일반 웹 서버에서는 이 상태 코드를 반환하지 않습니다. 하지만 WebDAV와 같은 일부 다른 프로토콜에서는 이 코드를 반환할 수 있습니다. 예를 들어, WebDAV에서 PROPPATCH 요청을 보냈을 때 하나의 명령이 실패하면 자동으로 다른 모든 명령도 424 Failed Dependency로 실패합니다.
425 Too Early
HTTP 425 Too Early 응답 상태 코드는 서버가 재전송 될 수 있는 요청을 처리하는 데 위험을 감수하기를 원하지 않으며, 이는 재전송 공격(replay attack)의 가능성을 만들 수 있다는 것을 나타냅니다.
426 Upgrade Required
HTTP 426 Upgrade Required 클라이언트 에러 응답 코드는 서버가 현재 프로토콜을 사용하여 요청을 처리하는 것은 거부하지만 클라이언트가 다른 프로토콜로 업그레이드한 후에는 요청을 수행할 의향이 있음을 나타냅니다.
서버는 필요한 하나 이상의 프로토콜을 나타내기 위해 이 응답에 Upgrade (en-US) 헤더를 같이 보냅니다.
428 Precondition Required
HTTP 428 Precondition Required 응답 상태 코드는 서버가 conditional 요청을 요구함을 나타냅니다.
일반적으로 이는 If-Match와 같은 필수 전제 조건 헤더가 누락되었음을 의미합니다.
전제 조건 헤더가 서버 측 상태와 일치하지 않는 경우 응답은 412 Precondition Failed 이어야 합니다.
429 Too Many Requests
HTTP 429 Too Many Requests 응답 상태 코드는 사용자가 주어진 시간 동안 너무 많은 요청을 보냈음을 나타냅니다("속도 제한").
새로운 요청을 하기 전에 얼마나 오래 대기해야 하는지를 알려주는 Retry-After 헤더가 이 응답에 포함될 수 있습니다
431 Request Header Fields Too Large
HTTP 431 Request Header Fields Too Large 응답 코드는 HTTP 헤더의 크기가 너무 크기 때문에 처리가 불가능함을 알려준다. 요청 헤더의 크기를 줄인 후, 재요청을 할 수 있다.
431는 헤더 전체의 크기가 너무 크거나, 단일 헤더 필드가 너무 클 경우에 사용된다. 이 에러를 받는 유저를 위해 응답 body에 둘 중에 어느 경우인지 명시해줄 수 있다 — 이상적으로, 어느 헤더가 처리 불가능한지 알려주면 좋다. 그러면 쿠키를 삭제하는 것과 같이 유저가 문제를 해결할 수 있도록 도와준다.
서버가 431 상태 코드를 전송할 경우:
451 Unavailable For Legal Reasons
HTTP 451 Unavailable For Legal Reasons 클라이언트 오류 응답 코드는 사용자가 법적 조치가 내려진 웹 페이지 등 법적 이유로 인해 사용할 수 없는 리소스를 요청했음을 나타냅니다
500 Internal Server Error
HTTP 500 Internal Server Error 서버 에러 응답 코드는 요청을 처리하는 과정에서 서버가 예상하지 못한 상황에 놓였다는 것을 나타냅니다.
이 에러 응답은 "서버 에러를 총칭하는"(catch-all) 일반적인 응답입니다. 보통 이는 서버가 응답할 좀 더 좋은 5xx 에러 코드를 못 찾은 것을 의미합니다. 종종 서버 관리자들은 미래에 같은 에러를 발생하는 것을 방지하기 위해 500 상태 코드 같은 에러 응답들에 더 많은 자세한 내용을 남겨 둡니다.
501 Not Implemented
HTTP 501 Not Implemented 서버 응답 코드는 요청을 수행할 수 있는 기능을 서버가 지원하지 않는다는 것을 의미합니다.
서버에서 추후 기능이 지원된다면 요청자에게 다시 확인해볼 수 있는 시점을 알려줄 수 있도록 Retry-After 헤더를 전송해줄 수 있습니다.
501 은 서버가 요청 방법을 이해하지 못하거나 어떤 리소스를 지원하지 않은 경우에 적절합니다. 서버가 필수적으로 지원하는 메서드에는 GET 와 HEAD가 있습니다.
서버가 메서드를 이해하지만 고의적으로 지원하지 않는 경우에는 405 Method Not Allowed 응답이 적합합니다.
502 Bad Gateway
HTTP 502 Bad Gateway 에러 응답코드는 서버가 게이트웨이나 프록시 서버 역할을 하면서 업스트림 서버로부터 유효하지 않은 응답을 받았다는 것을 의미합니다.
Gateway 는 네트워킹에서 다른 것을 가르킬 수 있고 502 에러는 보통 여러분이 수정할 수 있는 것이 아니지만, 여러분이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.
503 Service Unavailable
HTTP 503 Service Unavailable 서버 에러 응답 코드는 서버가 요청을 처리할 준비가 되지 않은 것을 의미합니다.
흔하게는 서버가 점검을 위해 다운되거나 과부하 때문에 발생합니다. 이 응답은 일시적인 상황을 위해 사용되어야 하며, Retry-After HTTP 헤더는 가능하다면 서비스 복구를 위한 예상 시간을 포함해야 합니다.
503 상태는 종종 일시적인 상황이며 응답은 일반적으로 캐시되지 않아야 하므로, 이 응답과 함께 전달되는 캐싱 관련 헤더들은 주의 깊게 다루어져야 합니다.
이 응답(response)과 함께, 이 문제에 대해 설명하는 사용자 친화적 페이지가 전달되어야 합니다.
504 Gateway Timeout
HTTP 504 Gateway Timeout 서버 에러 응답 코드는 서버가 게이트웨이 혹은 프록시의 역할을 하는 동안 시간 안에 업스트림 서버(upstream server)로부터 요청을 마치기 위해 필요한 응답를 받지 못했음을 나타냅니다.
Gateway 는 네트워킹에서 다른 것을 가르킬 수 있고 504 에러는 보통 여러분이 수정할 수 있는 것이 아니지만, 여러분이 접근하려고 하는 웹 서버 혹은 프록시의 수정이 필요합니다.
505 HTTP Version Not Supported
505 HTTP Version Not Supported 응답 코드는 요청에 사용된 HTTP 버전을 서버가 지원하지 않음을 의미합니다
506 Variant Also Negotiates
HTTP 506 Variant Also Negotiates 응답 상태 코드는 투명한 콘텐츠 협상의 맥락에서 제공될 수 있습니다 (RFC 2295). 이 프로토콜을 통해 클라이언트는 서버가 여러 변형을 지원하는 경우 주어진 리소스의 최상의 변형을 검색할 수 있습니다.
Variant Also Negotiates 상태 코드는 선택한 변형 자체가 콘텐츠 협상에 참여하도록 구성된 내부 서버 구성 오류를 나타내므로 적절한 협상 엔드포인트가 아닙니다.
507 Insufficient Storage
HTTP 507 Insufficient Storage 응답 상태 코드는 웹 분산 저작 및 버전 관리(WebDAV) 프로토콜의 컨텍스트에서 제공될 수 있습니다 (RFC 4918).
서버가 요청을 성공적으로 완료하는 데 필요한 표현을 저장할 수 없기 때문에 메서드를 수행할 수 없음을 나타냅니다.
508 Loop Detected
HTTP 508 Loop Detected 응답 상태 코드는 웹 분산 저작 및 버전 관리(WebDAV) 프로토콜의 컨텍스트에서 제공될 수 있습니다.
이 상태는 서버가 "깊이: 무한대"의 요청을 처리하는 동안 무한대 루프가 발생하여 작업을 종료했음을 나타냅니다. 이 상태는 전체 작업이 실패했음을 나타냅니다.
510 Not Extended
HTTP 510 Not Extended 응답 상태 코드는 RFC 2774에 정의된 HTTP 확장 프레임워크의 컨텍스트에서 전송됩니다.
이 사양에서 클라이언트는 사용할 확장을 설명하는 확장 선언이 포함된 요청을 보낼 수 있습니다. 서버가 이러한 요청을 수신했지만 해당 요청에 대해 설명된 확장이 지원되지 않는 경우 서버는 510 상태 코드로 응답합니다.