| HTTP 상태 코드 |
상태 코드 의미 |
| 100 |
클라이언트는 요청을 계속 보내야 합니다. 이 임시 응답은 클라이언트에게 요청의 일부가 서버에 수신되었으며 여전히 거부되지 않았음을 알리기 위해 사용됩니다. 클라이언트는 남은 요청을 계속 보내거나 요청이 완료되었다면 이 응답을 무시해야 합니다. 서버는 요청이 완료된 후 클라이언트에게 최종 응답을 보내야 합니다. |
| 101 |
서버는 클라이언트의 요청을 이해하였으며, Upgrade 메시지 헤더를 통해 클라이언트에게 요청을 완료하기 위해 다른 프로토콜을 사용할 것임을 알립니다. 이 응답의 마지막 빈 줄을 보낸 후 서버는 Upgrade 메시지 헤더에 정의된 프로토콜로 전환됩니다. 새로운 프로토콜로 전환이 더 유리할 때만 이와 같은 조치를 취해야 합니다. 예를 들어, 새로운 HTTP 버전으로 전환하는 것이 이전 버전보다 더 나은 경우이거나 실시간으로 동기화된 프로토콜로 전환하여 이러한 특성을 활용하는 리소스를 전송할 때입니다. |
| 102 |
WebDAV(RFC 2518) 확장 상태 코드로, 처리가 계속 진행됨을 나타냅니다. |
| 200 |
요청이 성공했으며, 요청된 응답 헤더 또는 데이터 본문이 함께 반환됩니다. |
| 201 |
요청이 수행되었고, 요청에 따라 새로운 리소스가 생성되었으며, 그 URI는 Location 헤더 정보로 반환됩니다. 필요한 리소스가 신속하게 생성되지 않을 경우 '202 Accepted'를 반환해야 합니다. |
| 202 |
서버는 요청을 수락했지만 아직 처리하지 않았습니다. 이 요청은 거부될 수 있으며, 최종적으로 이 요청이 실행될 수도 있고 실행되지 않을 수도 있습니다. 비동기 작업의 경우 이 상태 코드를 보내는 것보다 더 간편한 방법은 없습니다. 상태 코드 202가 반환된 응답의 목적은 서버가 다른 프로세스의 요청을 수락할 수 있도록 하면서 클라이언트가 배치 작업이 모두 완료될 때까지 서버와 계속 연결할 필요가 없도록 하는 것입니다. 요청 처리 수락 및 202 상태 코드 반환 응답은 반환된 엔터티 내에 현재 상태에 대한 정보를 포함해야 하며, 사용자가 작업이 완료되었는지 예측할 수 있도록 처리를 모니터링하거나 상태 예측할 수 있는 지점을 포함해야 합니다. |
| 203 |
서버가 요청을 성공적으로 처리했지만 반환된 엔터티 헤더의 메타 정보가 원래 서버에서 유효한 식별된 집합이 아니라 로컬 또는 제3자로부터의 복사본입니다. 현재 정보는 원본 버전의 하위 집합 또는 상위 집합일 수 있습니다. 예를 들어, 리소스를 포함하는 메타데이터는 원래 서버가 메타 정보의 슈퍼임을 알릴 수도 있습니다. 이 상태 코드를 사용하는 것은 필수가 아니며 응답이 이 상태 코드를 사용하지 않았을 경우 200 OK를 반환하는 경우에만 적절합니다. |
| 204 |
서버가 요청을 성공적으로 처리했지만 엔터티 콘텐츠를 반환할 필요가 없으며 업데이트된 메타 정보를 반환하고자 합니다. 응답은 엔터티 헤더 형식으로 새로운 또는 업데이트된 메타 정보를 반환할 수 있습니다. 이러한 헤더 정보가 존재할 경우 요청된 변수와 연관되어야 합니다. 클라이언트가 브라우저인 경우, 사용자가 해당 요청을 보낸 페이지를 유지해야 하며 문서 뷰에는 아무런 변화가 없어야 합니다. 비록 명세에 따라 새로운 또는 업데이트된 메타 정보가 사용자 브라우저의 활동 뷰에 문서에 적용되어야 하나, 204 응답은 메시지 본문을 포함하는 것이 금지되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 205 |
서버가 요청을 성공적으로 처리했으며 아무 내용도 반환하지 않았습니다. 그러나 204 응답과는 달리, 이 상태 코드를 반환하는 응답은 요청자가 문서 뷰를 재설정하도록 요구합니다. 이 응답은 주로 사용자의 입력 후에 즉시 양식을 재설정하기 위해 사용됩니다. 사용자가 입력을 쉽게 시작할 수 있도록 하기 위함입니다. 204 응답과 마찬가지로, 이 응답도 메시지 본문을 포함하는 것이 금지되며 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 206 |
서버는 일부 GET 요청을 성공적으로 처리했습니다. FlashGet 또는 Thunder와 같은 HTTP 다운로드 도구는 이러한 응답을 사용하여 중단 지점을 계속하거나 큰 문서를 여러 다운로드 섹션으로 나누어 동일하게 다운로드합니다. 이 요청은 Range 헤더 정보를 포함해야 하며, 클라이언트가 받고자 하는 내용의 범위를 지정해야 합니다. 응답은 다음과 같은 헤더 필드를 포함해야 합니다: Content-Range, 이 응답에서 경계 영역으로 반환된 콘텐츠의 범위를 지시합니다. 만약 Content-Type이 multipart/byteranges인 경우, 각 multipart 섹션 내에 Content-Range 필드를 포함해 이 섹션의 콘텐츠 범위를 지시해야 합니다. 응답에 Content-Length가 포함되면 그 값은 반환된 콘텐츠 범위의 실제 바이트 수와 일치해야 합니다. Date ETag 및/또는 Content-Location, 동일한 요청이 본래 200 응답을 반환해야 한다면. Expires, Cache-Control, 및/또는 Vary, 이 값이 이전에 동일한 변수의 다른 응답에 대한 값과 다를 수 있는 경우. 만약 본 응답 요청이 If-Range 강력 캐시 검증을 사용했다면, 본 응답은 다른 엔터티 헤드를 포함해서는 안 됩니다; 만약 본 응답 요청이 If-Range 약한 캐시 검증을 사용했다면, 본 응답은 다른 엔터티 헤드를 포함하는 것이 금지됩니다; 이는 캐시된 엔터티 콘텐츠와 업데이트된 엔터티 헤드 정보 간의 불일치를 피하기 위함입니다. 그렇지 않으면 본 응답은 본래 200 응답에서 반환해야 하는 모든 엔터티 헤더 필드를 포함해야 합니다. 만약 ETag 또는 Last-Modified 헤더가 정확히 일치하지 않는다면, 클라이언트 캐시는 206 응답으로 반환된 내용을 이전에 캐시된 내용과 결합하는 것을 금지해야 합니다. Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206 응답으로 반환된 내용을 캐시하는 것이 금지됩니다. |
| 207 |
WebDAV(RFC 2518) 확장 상태 코드로, 이후 메시지 본문은 XML 메시지이며 이전 하위 요청 수에 따라 독립적인 응답 코드를 포함할 수 있습니다. |
| 300 |
요청된 리소스에 대해 여러 개의 선택 가능한 피드백 정보가 있으며, 각자 고유한 주소와 브라우저 동작의 메시지 정보가 있습니다. 사용자나 브라우저는 선호하는 주소를 선택하여 리디렉션할 수 있습니다. HEAD 요청이 아닌 경우 이 응답은 리소스 속성 및 주소 목록을 포함하는 엔터티를 포함해야 하며, 사용자 또는 브라우저가 가장 적합한 리디렉션 주소를 선택할 수 있도록 해야 합니다. 이 엔터티의 형식은 Content-Type으로 정의된 형식에 의해서 결정됩니다. 브라우저는 응답 형식과 자체 능력에 따라 자동으로 가장 적합한 선택을 할 수 있습니다. 물론 RFC 2616 명세에서는 그러한 자동 선택이 어떻게 이루어져야 하는지 명시하지 않았습니다. 서버가 이미 기본 피드백 선택을 갖고 있다면, Location에 이 피드백의 URI를 명시해야 합니다; 브라우저는 이 Location 값을 자동 리디렉션 주소로 사용할 수 있습니다. 추가로 명시하지 않는 한 이 응답도 캐시할 수 있습니다. |
| 301 |
요청된 리소스는 새로운 위치로 영구적으로 이동되었으며, 앞으로 해당 자원에 대한 모든 참조는 이 응답이 반환한 URI 중 하나를 사용해야 합니다. 가능하면 링크 편집 기능이 있는 클라이언트는 요청 주소를 서버가 반환한 주소로 자동으로 수정해야 합니다. 추가로 명시하지 않는 한 이 응답도 캐시할 수 있습니다. 새로운 영구적인 URI는 응답의 Location 필드에서 반환되어야 합니다. HEAD 요청이 아닌 경우 응답의 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 이것이 GET 또는 HEAD 요청이 아니면, 브라우저는 자동적으로 리디렉션을 하지 못합니다; 사용자의 확인이 있어야 합니다, 요청의 조건이 변경될 수 있기 때문입니다. 주의: 일부 HTTP/1.0 프로토콜을 사용한 브라우저는 POST 요청에 301 응답을 받았을 때, 이후 리디렉션 요청이 GET 방식으로 변환됩니다. |
| 302 |
요청된 리소스는 현재 임시로 다른 URI로 응답합니다. 이러한 리디렉션이 임시적이므로 클라이언트는 원래 주소로 계속 요청을 보내야 합니다. Cache-Control 또는 Expires에 지정된 경우에만 이 응답은 캐시할 수 있습니다. 새로운 임시 URI는 응답의 Location 필드에서 반환되어야 합니다. HEAD 요청이 아닌 경우 응답의 엔터티에는 새로운 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 이것이 GET 또는 HEAD 요청이 아니면, 브라우저는 자동적으로 리디렉션을 하지 못합니다; 사용자의 확인이 필요합니다, 요청의 조건이 변경될 수 있기 때문입니다. 주의: RFC 1945 및 RFC 2068 명세에서는 클라이언트가 리디렉션 시 요청 방법을 변경하는 것을 허용하지 않지만, 많은 기존 브라우저들은 302 응답을 303 응답으로 취급하고, Location에 명시된 URI를 GET 방식으로 접근하며 원래 요청 방법을 무시합니다. 상태 코드 303 및 307은 서버가 클라이언트에 대해 어떤 반응을 기대하는지를 분명히 하기 위해 추가되었습니다. |
| 303 |
현재 요청에 대한 응답은 다른 URI에서 찾을 수 있으며, 클라이언트는 그 리소스에 접근하기 위해 GET 방식을 사용해야 합니다. 이 방법의 목적은 스크립트로 활성화된 POST 요청의 출력을 새로운 리소스로 리디렉션 가능하도록 허용하기 위함입니다. 이 새로운 URI는 원래 리소스의 대체 참조가 아닙니다. 물론, 303 응답은 캐시할 수 없습니다. 두 번째 요청(리디렉션)은 캐시될 수 있습니다. 새로운 URI는 응답의 Location 필드에서 반환되어야 합니다. HEAD 요청이 아닌 경우 응답의 엔터티에는 새로운 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 주의: 많은 HTTP/1.1 이전 버전의 브라우저는 303 상태 코드를 정확하게 이해하지 못합니다. 이러한 브라우저와의 상호 작용을 고려해야 할 경우, 302 상태 코드가 적절합니다, 많은 브라우저는 302 응답 처리 방식이 바로 위의 명세에서 클라이언트가 303 응답을 처리할 때 요구되는 방식입니다. |
| 304 |
클라이언트가 조건부 GET 요청을 보내고 이 요청이 허용되었으며, 문서 내용이(마지막 접속 이후 또는 요청 조건에 따라) 변경되지 않았을 경우 서버는 이 상태 코드를 반환해야 합니다. 304 응답은 메시지 본문을 포함하는 것이 금지되며 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. 이 응답은 다음의 헤더 정보를 포함해야 합니다: Date, 이 서버에 시계가 없는 경우 제외합니다. 시계가 없는 서버가 이런 규칙을 준수한다면 프록시 서버와 클라이언트가 수신 응답 헤드에 Date 필드를 추가할 수 있습니다(RFC 2068에 명시된 대로), 캐시 메커니즘은 정상적으로 작동합니다. ETag 및/또는 Content-Location, 동일한 요청이 200 응답을 반환해야 하는 경우. Expires, Cache-Control, 및/또는 Vary, 이 값이 이전에 동일한 변수가 다른 응답에 따라 다를 수 있는 경우. 만약 본 응답 요청이 강제 캐시 검증을 사용했다면, 본 응답은 다른 엔터티 헤드를 포함해서는 안 됩니다; 그렇지 않으면(예를 들어 조건부 GET 요청이 약한 캐시 검증을 사용하는 경우), 본 응답은 다른 엔터티 헤드를 포함해서는 안 됩니다; 이는 캐시된 엔터티 콘텐츠와 업데이트된 엔터티 헤드 정보 간의 불일치를 피하기 위함입니다. 만약 304 응답이 특정 엔터티가 캐시된 것이 아니라면, 캐시 시스템은 이 응답을 무시하고 제약 조건 없는 요청을 반복해서 발송해야 합니다. 만약 304 응답을 수신하고 특정 캐시 항목을 업데이트해야 한다면, 캐시 시스템은 응답에서 업데이트된 필드 값에 따라 전체 항목을 업데이트해야 합니다. |
| 305 |
요청된 리소스는 지정된 프록시를 통해서만 접근할 수 있습니다. Location 필드에는 지정된 프록시의 URI 정보가 제공되며, 수신자는 해당 프록시를 통해 요청을 반복해야 합니다. 오직 원래 서버만 305 응답을 생성할 수 있습니다. 주의: RFC 2068은 305 응답이 단일 요청을 리디렉션하기 위한 것이며 원래 서버만 생성할 수 있다고 명시하지 않았습니다. 이러한 제한을 무시하면 심각한 보안상의 결과를 초래할 수 있습니다. |
| 306 |
최신 사양에서 306 상태 코드는 더 이상 사용되지 않습니다. |
| 307 |
요청된 리소스는 현재 임시로 다른 URI로 응답합니다. 이러한 리디렉션이 임시적이므로 클라이언트는 원래 주소로 계속 요청을 보내야 합니다. Cache-Control 또는 Expires에 의해 지정된 경우에만 이 응답은 캐시할 수 있습니다. 새로운 임시 URI는 응답의 Location 필드에서 반환되어야 합니다. HEAD 요청이 아닌 경우 응답의 엔터티에는 새로운 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 일부 브라우저가 307 응답을 인식하지 못할 수 있으므로 사용자들이 이해하고 새로운 URI에 대한 요청을 할 수 있도록 필요한 정보를 추가해야 합니다. 이것이 GET 또는 HEAD 요청이 아니면, 브라우저는 자동적으로 리디렉션을 하지 못합니다; 사용자의 확인이 필요합니다, 요청의 조건이 변경될 수 있기 때문입니다. |
| 400 |
1. 의미가 잘못되어 현재 요청을 서버가 이해할 수 없습니다. 수정하지 않는 한 클라이언트는 이 요청을 반복해서 제출하지 않아야 합니다. 2. 요청 매개변수가 잘못되었습니다. |
| 401 |
현재 요청은 사용자 인증이 필요합니다. 이 응답은 요청된 리소스에 적합한 WWW-Authenticate 정보 헤더를 포함하여 사용자 정보를 요청해야 합니다. 클라이언트는 적절한 Authorization 헤더가 포함된 요청을 반복 제출할 수 있습니다. 현재 요청이 이미 인증서가 포함되어 있다면 401 응답은 서버가 해당 인증서를 거부했음을 나타냅니다. 401 응답이 이전 응답과 동일한 인증 요청을 포함하고 있으며 브라우저가 최소한 한 번 인증을 시도한 경우, 브라우저는 응답에 포함된 엔터티 정보를 사용자에게 표시해야 하며 이 엔터티 정보에는 관련 진단 정보가 포함되어 있을 수 있습니다. RFC 2617을 참조하십시오. |
| 402 |
이 상태 코드는 미래의 요구를 위해 예약되어 있습니다. |
| 403 |
서버가 요청을 이해했지만 실행을 거부했습니다. 401 응답과는 달리 인증이 아무런 도움을 제공하지 않으며 이 요청은 반복적으로 제출해서는 안 됩니다. 이것이 HEAD 요청이 아니면 서버가 요청이 수행될 수 없는 이유를 설명하려고 한다면 엔터티 내에 거부 이유를 서술해야 합니다. 물론 서버는 404 응답을 반환할 수도 있습니다, 클라이언트가 어떤 정보도 얻고 싶지 않은 경우입니다. |
| 404 |
요청이 실패했으며 요청된 리소스가 서버에 존재하지 않습니다. 사용자에게 이 상태가 일시적인지 영구적인지를 알려줄 정보가 없습니다. 서버가 상황을 알고 있다면 410 상태 코드를 사용하여 과거 리소스가 내부 구성 메커니즘 문제로 인해 영구적으로 사용할 수 없고 전환할 수 있는 주소가 없음을 알릴 수 있습니다. 404 이 상태 코드는 서버가 요청이 거부된 이유를 밝히고 싶지 않거나 적절한 다른 응답이 없는 경우에 널리 사용됩니다. |
| 405 |
요청 라인에서 지정된 요청 방법이 요청된 리소스에 사용할 수 없습니다. 이 응답은 현재 리소스가 수용할 수 있는 요청 방법 목록을 표시하기 위해 Allow 헤더 정보를 반환해야 합니다. PUT, DELETE 방법은 서버의 리소스에 대해 쓰기 작업을 수행하므로 대부분의 웹 서버는 이러한 요청 방법을 지원하지 않거나 기본 구성에서는 허용하지 않습니다. 이러한 요청은 모두 405 오류를 반환합니다. |
| 406 |
요청한 리소스의 콘텐츠 특성이 요청 헤더의 조건을 충족할 수 없어 응답 엔터티를 생성할 수 없습니다. 이것이 HEAD 요청이 아닌 경우 이 응답은 사용자 또는 브라우저가 가장 적합한 엔터티 특성 및 주소 목록을 선택할 수 있도록 엔터티를 반환해야 합니다. 엔터티의 형식은 Content-Type 헤더에서 정의된 미디어 타입에 따라 결정됩니다. 브라우저는 형식 및 자체 능력에 따라 최적의 선택을 할 수 있습니다. 그러나 규정상 이러한 자동 선택을 결정할 수 있는 기준은 없습니다. |
| 407 |
401 응답과 유사하지만, 클라이언트는 프록시 서버에서 인증해야 합니다. 프록시 서버는 인증 요청을 위해 Proxy-Authenticate를 반환해야 합니다. 클라이언트는 Proxy-Authorization 정보 헤더를 통해 인증할 수 있습니다. RFC 2617을 참조하십시오. |
| 408 |
요청 시간 초과. 클라이언트가 서버가 기다리는 시간 안에 요청을 완료하지 않았습니다. 클라이언트는 이 요청을 언제든지 변경 없이 다시 제출할 수 있습니다. |
| 409 |
현재 요청이 요청된 리소스의 상태와 충돌하여 완료될 수 없습니다. 이 코드는 사용자가 충돌을 해결할 수 있는 경우에만 사용할 수 있으며, 새 요청을 반복 제출할 것입니다. 이 응답은 사용자가 충돌의 원인을 찾을 수 있도록 충분한 정보를 포함해야 합니다. 충돌은 일반적으로 PUT 요청의 처리 중에 발생합니다. 예를 들어, 버전 확인이 포함된 환경에서 특정 리소스에 대한 PUT 요청이 명시한 버전 정보가 이전 요청(서드파티)과 충돌하는 경우 이 서버는 409 오류를 반환해야 하며 사용자는 요청을 완료할 수 없습니다. 이 경우 응답 엔터티에는 두 버전 간의 차이를 비교하여 사용자가 병합 후의 새 버전을 제출할 수 있도록 할 수 있습니다. |
| 410 |
요청된 리소스는 서버에서 더 이상 사용할 수 없으며, 알려진 전환 주소가 없습니다. 이러한 상황은 영구적인 것으로 간주되어야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 사용자의 동의를 받아 이 주소에 대한 모든 참조를 삭제해야 합니다. 서버가 이 상황이 영구적인지가 불확실한 경우 404 상태 코드를 사용해야 합니다. 추가 설명이 없는 한 이 응답은 캐시할 수 있습니다. 410 응답의 목적은 웹사이트 관리자가 웹사이트를 유지 관리하고 사용자가 해당 리소스가 더 이상 사용 가능하지 않음을 미리 경고하는 것입니다. |
| 411 |
서버가 Content-Length 헤더를 정의하지 않은 상태에서 요청을 수락하지 않습니다. 유효한 Content-Length 헤더가 추가된 후 클라이언트는 이 요청을 다시 제출할 수 있습니다. |
| 412 |
서버가 요청 헤더 필드에서 제공된 사전 조건을 확인하는 데 실패했습니다. 이 상태 코드는 클라이언트가 리소스를 가져올 때 요청 메타 정보를 설정하여 시작하여 해당 요청 방법이 희망하는 콘텐츠 외의 리소스에 적용되지 않도록 할 수 있습니다. |
| 413 |
서버가 현재 요청을 처리할 수 없으며 요청 엔터티 데이터의 크기가 서버가 처리할 수 있는 범위를 초과했습니다. 이 경우 서버는 클라이언트가 이 요청을 계속 전송하지 않도록 연결을 종료할 수 있습니다. 이 상태가 일시적이라면 서버는 Retry-After 응답 헤더를 반환하여 클라이언트가 언제 다시 시도할 수 있는지 알릴 수 있습니다. |
| 414 |
요청된 URI의 길이가 서버가 해석할 수 있는 길이를 초과하므로 서버는 해당 요청을 제공할 수 없습니다. 이것은 드물며 일반적으로 POST 방법으로 사용해야 할 양식 제출이 GET 방법으로 변환되어 쿼리 문자열이 너무 긴 경우에 발생합니다. 리디렉션 URI "블랙홀", 예를 들어 매번 리디렉션할 때 이전 URI를 새로운 URI의 일부로 만들며 여러 차례의 리디렉션 후에 URI가 초과될 때 발생합니다. 클라이언트가 기존 서버의 보안 취약점을 이용하려고 시도하는 경우입니다. 이와 같은 서버는 고정 길이의 버퍼를 사용하여 URI를 읽거나 조작하며, GET 요청의 매개변수가 특정 숫자를 초과하면 버퍼 오버플로우를 발생시켜 임의의 코드가 실행될 수 있습니다. 이러한 취약점이 없는 서버는 414 상태 코드를 반환해야 합니다. |
| 415 |
현재 요청의 방법과 요청된 리소스에 대해 요청된 엔터티는 서버에서 지원하는 형식이 아니므로 요청이 거부되었습니다. |
| 416 |
요청에 Range 요청 헤드가 포함되고 Range에서 지정된 데이터 범위가 현재 리소스의 사용 가능한 범위와 일치하지 않으며, 요청에 If-Range 요청 헤더가 정의되어 있지 않은 경우 서버는 416 상태 코드를 반환해야 합니다. Range가 바이트 범위를 사용하는 경우, 이 경우 요청이 지정된 모든 데이터 범위의 첫 번째 바이트 위치가 현재 리소스의 길이를 초과해야 합니다. 서버는 416 상태 코드를 반환할 때 현재 리소스의 길이를 명시하는 Content-Range 엔터티 헤더를 포함해야 합니다. 이 응답은 Content-Type으로 multipart/byteranges를 사용하는 것이 금지됩니다. |
| 417 |
요청 헤더 Expect에 지정된 기대 내용이 서버에 의해 충족되지 않거나 이 서버가 프록시 서버인 경우 현재 라우팅에서 다음 노드에서 Expect의 내용이 충족되지 않는 것을 명백히 증명하는 경우입니다. |
| 421 |
현재 클라이언트의 IP 주소에서 서버까지의 연결 수가 서버에서 허용하는 최대 범위를 초과했습니다. 일반적으로 이 IP 주소는 서버에서 보는 클라이언트 주소(예: 사용자의 게이트웨이나 프록시 서버 주소)를 의미합니다. 이러한 경우 연결 수 계산이 여러 최종 사용자와 관련될 수 있습니다. |
| 422 |
요청 형식은 올바르지만 의미상의 오류로 인해 응답할 수 없습니다.(RFC 4918 WebDAV)423 Locked 현재 리소스가 잠겨 있습니다.(RFC 4918 WebDAV) |
| 424 |
이전 요청 중 발생한 오류로 인해 현재 요청이 실패했습니다. 예: PROPPATCH.(RFC 4918 WebDAV) |
| 425 |
WebDav Advanced Collections 초안에서 정의되었으나 이를 WebDAV 순서집합 프로토콜(RFC 3658)에서 나타나지 않았습니다. |
| 426 |
클라이언트는 TLS/1.0으로 전환해야 합니다.(RFC 2817) |
| 449 |
마이크로소프트에 의해 확장되어 요청이 적절한 작업을 수행한 후 다시 시도해야 함을 나타냅니다. |
| 500 |
서버는 예기치 않은 상황에 직면하여 요청 처리를 완료할 수 없었습니다. 일반적으로 이 문제는 서버의 프로그래밍 오류가 발생할 때 나타납니다. |
| 501 |
서버가 현재 요청을 수행하는 데 필요한 기능을 지원하지 않습니다. 서버가 요청 방법을 인식하지 못하거나 리소스에 대한 요청을 지원할 수 없는 경우입니다. |
| 502 |
게이트웨이 또는 프록시 서버가 요청을 실행할 때 상위 서버로부터 유효하지 않은 응답을 수신했습니다. |
| 503 |
일시적인 서버 유지 관리 또는 과부하로 인해 서버가 현재 요청을 처리할 수 없습니다. 이 상태는 일시적이며 수 시간이 지나면 복구됩니다. 지연 시간을 예측할 수 있는 경우 응답에는 이 지연 시간을 명시하는 Retry-After 헤더를 포함할 수 있습니다. 이 Retry-After 정보가 제공되지 않으면 클라이언트는 500 응답을 처리하는 방식으로 이 응답을 처리해야 합니다. 주의: 503 상태 코드가 있다는 것은 서버가 과부하되어 있을 때 반드시 사용하는 것이 아님을 의미합니다. 일부 서버는 단순히 클라이언트의 연결을 거부할 수 있습니다. |
| 504 |
게이트웨이 또는 프록시가 요청을 실행할 때 상위 서버(URI로 식별된 서버, 예: HTTP, FTP, LDAP) 또는 보조 서버(예: DNS)로부터 적시에 응답을 받지 못했습니다. 주의: 일부 프록시 서버는 DNS 쿼리 시간 초과 시 400 또는 500 오류를 반환할 수 있습니다. |
| 505 |
서버가 요청에 사용된 HTTP 버전을 지원하지 않거나 지원하지 않겠다고 거부합니다. 이는 서버가 클라이언트와 동일한 버전을 사용하지 않거나 사용할 수 없음을 의미합니다. 응답에는 어떤 버전이 지원되지 않는지 이유를 설명하고 서버가 어떤 프로토콜을 지원하는지 설명하는 엔터티가 포함되어야 합니다. |
| 506 |
투명 내용 협상 프로토콜(RFC 2295)에 의해 확장되어, 서버의 내부 구성 오류를 나타냅니다: 요청된 협상 변수 리소스가 투명 내용 협상에 대해 자신을 사용하도록 구성되어 있습니다. |
| 507 |
서버는 요청을 완료하는 데 필요한 콘텐츠를 저장할 수 없습니다. 이 상태는 일시적인 것으로 간주됩니다. WebDAV(RFC 4918) |
| 509 |
서버가 대역폭 제한에 도달했습니다. 이는 공식 상태 코드는 아니지만 여전히 널리 사용됩니다. |
| 510 |
리소스를 얻는 데 필요한 정책이 충족되지 않았습니다.(RFC 2774) |