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