| 100 |
클라이언트는 계속해서 요청을 보내야 합니다. 이 임시 응답은 요청의 일부가 서버에 의해 수신되었으며 아직 거부되지 않았음을 클라이언트에 알리는 데 사용됩니다. 클라이언트는 요청의 나머지 부분을 계속 보내야 하며, 요청이 이미 완료된 경우 이 응답을 무시해야 합니다. 서버는 요청이 완료된 후 클라이언트에 최종 응답을 보내야 합니다. |
| 101 |
서버는 클라이언트의 요청을 이해했으며 업그레이드 메시지 헤더를 통해 클라이언트에게 다른 프로토콜을 사용하여 요청을 완료하도록 알립니다. 이 응답의 마지막 빈 줄을 보낸 후 서버는 업그레이드 헤더에 정의된 프로토콜로 전환합니다. 새로운 프로토콜로 전환하는 것이 더 유리할 경우에만 유사한 조치를 취해야 합니다. 예를 들어, 이전 버전이 아닌 새로운 HTTP 버전으로 전환하거나, 이러한 기능을 활용하는 리소스를 전달하기 위해 실시간 및 동기 프로토콜로 전환하면 이점이 있습니다. |
| 102 |
WebDAV(RFC 2518)에 의해 확장된 상태 코드로, 처리가 계속됨을 나타냅니다. |
| 200 |
요청이 성공했으며 요청에서 예상하는 응답 헤더 또는 데이터 본문이 이 응답과 함께 반환됩니다. |
| 201 |
요청이 이행되었으며 요청의 요구 사항에 따라 새 리소스가 생성되었으며 해당 URI가 위치 헤더 정보와 함께 반환되었습니다. 필요한 리소스를 제때 생성할 수 없는 경우 '202 Accepted'를 반환해야 합니다. |
| 202 |
서버가 요청을 수락했지만 아직 처리하지 않았습니다. 거부될 수 있는 것처럼 요청도 궁극적으로 실행될 수도 있고 실행되지 않을 수도 있습니다. 비동기 작업의 경우 이 상태 코드를 보내는 것보다 더 편리한 방법은 없습니다. 202 상태 코드 응답을 반환하는 목적은 일괄 작업이 완료될 때까지 클라이언트를 서버에 연결하지 않고도 서버가 다른 프로세스의 요청(예: 하루에 한 번만 수행되는 일괄 기반 작업)을 수락할 수 있도록 하는 것입니다. 완료되었습니다. 요청 처리를 수락하고 202 상태 코드를 반환하는 응답에는 반환된 엔터티에 처리의 현재 상태를 나타내는 일부 정보와 처리 상태 모니터 또는 상태 예측에 대한 포인터가 포함되어 사용자가 작업 여부를 추정할 수 있습니다. 완료되었습니다. |
| 203 |
서버가 요청을 성공적으로 처리했지만 반환된 엔터티 헤더 메타 정보는 원래 서버에서 유효한 명확한 세트가 아니라 로컬 또는 제3자의 복사본입니다. 현재 정보는 원래 버전의 하위 집합이거나 상위 집합일 수 있습니다. 예를 들어, 리소스에 대한 메타데이터를 포함하면 원본 서버가 메타데이터에 대한 상위 정보를 알 수 있습니다. 이 상태 코드를 사용할 필요는 없으며 이 상태 코드 없이 응답이 200 OK를 반환한 경우에만 적합합니다. |
| 204 |
서버가 요청을 성공적으로 처리했지만 엔터티 콘텐츠를 반환할 필요가 없으며 업데이트된 메타 정보를 반환하려고 합니다. 응답은 엔터티 헤더 형식으로 새롭거나 업데이트된 메타정보를 반환할 수 있습니다. 이러한 헤더가 있는 경우 요청된 변수와 일치해야 합니다. 클라이언트가 브라우저인 경우, 사용자의 브라우저는 보기에 있는 문서 사양에 따라 새롭거나 업데이트된 메타정보가 사용자의 브라우저 활동에 적용되어야 하는 경우에도 문서 보기를 변경하지 않고 요청이 이루어진 페이지를 유지해야 합니다. 204 응답은 메시지 본문을 포함하는 것이 금지되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 205 |
서버가 요청을 성공적으로 처리했지만 아무것도 반환하지 않았습니다. 그러나 204 응답과 달리 이 상태 코드를 반환하는 응답에서는 요청자가 문서 보기를 재설정해야 합니다. 이 응답은 주로 사용자 입력을 수락한 후 즉시 양식을 재설정하여 사용자가 다른 입력을 쉽게 시작할 수 있도록 하는 데 사용됩니다. 204 응답과 마찬가지로 이 응답은 메시지 본문을 포함할 수 없으며 메시지 헤더 다음의 첫 번째 빈 줄로 끝납니다. |
| 206 |
서버가 GET 요청의 일부를 성공적으로 처리했습니다. FlashGet 또는 Thunder와 같은 HTTP 다운로드 도구는 이러한 유형의 응답을 사용하여 중단된 다운로드를 재개하거나 동시 다운로드를 위해 대용량 문서를 여러 다운로드 세그먼트로 나눕니다. 요청에는 클라이언트가 얻으려는 콘텐츠 범위를 나타내는 Range 헤더가 포함되어야 하며 요청 조건으로 If-Range가 포함될 수 있습니다. 응답에는 다음 헤더 필드가 포함되어야 합니다. Content-Range는 이 응답에 반환된 콘텐츠 범위를 나타내는 데 사용됩니다. Content-Type multipart/byteranges가 포함된 멀티파트 다운로드인 경우 각 멀티파트 파트에는 Content-Range가 포함되어야 합니다. 도메인은 이 단락의 내용 범위를 나타내는 데 사용됩니다. Content-Length가 응답에 포함된 경우 해당 값은 반환되는 콘텐츠 범위의 실제 바이트 수와 일치해야 합니다. 동일한 요청이 200 응답을 반환해야 하는 경우 날짜 ETag 및/또는 Content-Location. 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 사양에서는 이러한 자동 선택을 수행하는 방법을 지정하지 않습니다. 서버 자체에 이미 기본 피드백 선택 항목이 있는 경우 이 피드백의 URI는 위치에 지정되어야 합니다. 브라우저는 이 위치 값을 자동 리디렉션을 위한 주소로 사용할 수 있습니다. 또한 달리 지정하지 않는 한 이 응답은 캐시 가능합니다. |
| 301 |
요청한 리소스가 새 위치로 영구적으로 이동되었으며, 향후 이 리소스에 대한 참조는 이 응답에서 반환된 여러 URI 중 하나를 사용해야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 요청된 주소를 서버에서 반환된 주소로 자동으로 수정해야 합니다. 별도로 지정하지 않는 한 이 응답도 캐시 가능합니다. 응답의 위치 필드에 새 영구 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: HTTP/1.0 프로토콜을 사용하는 일부 브라우저의 경우 보내는 POST 요청이 301 응답을 받으면 후속 리디렉션 요청은 GET 메서드가 됩니다. |
| 302 |
이제 요청된 리소스가 다른 URI의 요청에 일시적으로 응답합니다. 이러한 리디렉션은 일시적이므로 클라이언트는 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache-Control 또는 Expires에 지정된 경우에만 캐시할 수 있습니다. 응답의 위치 필드에 새 임시 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. GET 또는 HEAD 요청이 아닌 경우 요청 조건이 그에 따라 변경될 수 있으므로 브라우저는 사용자가 확인하지 않는 한 자동 리디렉션을 금지합니다. 참고: RFC 1945 및 RFC 2068 사양에서는 리디렉션 시 클라이언트가 요청 방법을 변경하는 것을 허용하지 않지만, 기존의 많은 브라우저에서는 302 응답을 303 응답으로 간주하고 위치에 관계없이 GET 메서드를 사용하여 Location에 지정된 URI에 액세스합니다. 원래 요청의 방법입니다. 서버가 클라이언트로부터 기대하는 응답을 명확히 하기 위해 상태 코드 303 및 307이 추가되었습니다. |
| 303 |
현재 요청에 해당하는 응답은 다른 URI에서 찾을 수 있으며 클라이언트는 해당 리소스에 액세스하려면 GET을 사용해야 합니다. 이 방법은 주로 스크립트 활성화 POST 요청 출력을 새 리소스로 리디렉션할 수 있도록 하기 위해 존재합니다. 이 새 URI는 원래 리소스에 대한 대체 참조가 아닙니다. 동시에 303 응답은 캐시되지 않습니다. 물론 두 번째 요청(리디렉션)은 캐시될 수 있습니다. 응답의 위치 필드에 새 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 참고: HTTP/1.1 이전의 많은 브라우저는 303 상태를 올바르게 이해하지 못합니다. 이러한 브라우저와의 상호 작용을 고려해야 하는 경우 302 상태 코드로 충분해야 합니다. 왜냐하면 대부분의 브라우저는 위 사양에서 클라이언트가 303 응답을 처리하도록 요구하는 방식과 정확히 동일하게 302 응답을 처리하기 때문입니다. |
| 304 |
클라이언트가 조건부 GET 요청을 보내고 요청이 허용되었지만 문서의 내용이 변경되지 않은 경우(마지막 액세스 이후 또는 요청 조건에 따라) 서버는 이를 반환해야 합니다. 상태 코드. 304 응답은 메시지 본문을 포함하는 것이 금지되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다.응답에는 다음 헤더 정보가 포함되어야 합니다. 날짜(서버에 시계가 없는 경우 제외). 시계가 없는 서버가 이러한 규칙을 따르는 경우 프록시 서버와 클라이언트는 RFC 2068에 지정된 대로 수신된 응답 헤더 자체에 날짜 필드를 추가할 수 있으며 캐싱 메커니즘은 정상적으로 작동합니다. ETag 및/또는 Content-Location(동일한 요청이 200 응답을 반환해야 하는 경우) Expires, Cache-Control 및/또는 Vary(해당 값이 동일한 변수에 대한 이전의 다른 응답에 해당하는 값과 다를 수 있는 경우) 이 응답 요청이 강력한 캐시 확인을 사용하는 경우 이 응답에는 다른 엔터티 헤더가 포함되어서는 안 됩니다. 그렇지 않으면(예: 조건부 GET 요청이 약한 캐시 확인을 사용함) 이 응답은 다른 엔터티 헤더를 포함하는 것이 금지됩니다. 엔터티 콘텐츠 및 업데이트된 엔터티 헤더 정보. 304 응답이 엔터티가 현재 캐시되지 않았음을 나타내는 경우 캐싱 시스템은 응답을 무시하고 제한 없이 요청을 반복해야 합니다. 캐시 항목 업데이트가 필요한 304 응답이 수신되면 캐시 시스템은 응답에서 업데이트된 모든 필드의 값을 반영하도록 전체 항목을 업데이트해야 합니다. |
| 305 |
요청된 리소스는 지정된 프록시를 통해 액세스해야 합니다. 지정된 프록시의 URI 정보는 위치 필드에 제공됩니다. 수신자는 이 프록시를 통해 해당 리소스에 액세스하기 위해 별도의 요청을 반복적으로 보내야 합니다. 원본 서버만 305 응답을 설정할 수 있습니다. 참고: RFC 2068은 305 응답이 단일 요청을 리디렉션하기 위한 것이며 원본 서버에서만 설정할 수 있음을 지정하지 않습니다. 이러한 제한 사항을 무시하면 심각한 안전 문제를 초래할 수 있습니다. |
| 306 |
최신 버전의 사양에서는 306 상태 코드가 더 이상 사용되지 않습니다. |
| 307 |
이제 요청된 리소스가 다른 URI의 요청에 일시적으로 응답합니다. 이러한 리디렉션은 일시적이므로 클라이언트는 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache-Control 또는 Expires에 지정된 경우에만 캐시할 수 있습니다. 응답의 위치 필드에 새 임시 URI가 반환되어야 합니다. 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 응답과 유사합니다. 프록시 서버는 ID 쿼리에 대해 프록시 인증을 반환해야 합니다. 클라이언트는 확인을 위해 Proxy-Authorization 헤더를 반환할 수 있습니다. RFC 2617을 참조하세요. |
| 408 |
요청 시간 초과. 서버가 대기할 준비가 된 시간 내에 클라이언트가 요청 전송을 완료하지 못했습니다. 클라이언트는 변경 사항 없이 언제든지 이 요청을 다시 제출할 수 있습니다. |
| 409 |
요청한 리소스의 현재 상태와 충돌하여 요청을 완료할 수 없습니다. 이 코드는 사용자가 충돌을 해결하고 새 요청을 다시 제출할 수 있다고 믿는 경우에만 사용해야 합니다. 응답에는 사용자가 충돌의 원인을 발견할 수 있을 만큼 충분한 정보가 포함되어야 합니다. 충돌은 일반적으로 PUT 요청을 처리할 때 발생합니다. 예를 들어 버전 확인을 사용하는 환경에서 PUT에서 제출한 특정 리소스에 대한 수정 요청에 첨부된 버전 정보가 이전(타사) 요청과 충돌하는 경우 서버는 이때 409 오류를 반환해야 합니다. 사용자에게 요청을 완료할 수 없다고 알립니다. 이때 응답 엔터티에는 충돌하는 두 버전 간의 차이점 비교가 포함될 가능성이 높으므로 사용자는 병합 후 새 버전을 다시 제출할 수 있습니다. |
| 410 |
요청한 리소스를 더 이상 서버에서 사용할 수 없으며 알려진 전달 주소가 없습니다. 그러한 상황은 영구적인 것으로 간주되어야 합니다. 가능하다면 링크 편집 기능이 있는 클라이언트는 사용자의 허가를 받아 이 주소에 대한 모든 참조를 제거해야 합니다. 서버가 조건이 영구적인지 여부를 모르거나 확인할 수 없는 경우 404 상태 코드를 사용해야 합니다. 달리 명시하지 않는 한 이 응답은 캐시 가능합니다. 410 응답의 목적은 주로 웹 사이트 관리자가 웹 사이트를 유지 관리하도록 돕고, 사용자에게 리소스를 더 이상 사용할 수 없음을 알리고, 서버 소유자는 이 리소스를 가리키는 모든 원격 연결도 삭제되기를 희망하는 것입니다. 이러한 유형의 사고는 시간이 제한된 부가 가치 서비스에서 흔히 발생합니다. 마찬가지로 410 응답은 원래 개인에게 속한 리소스를 현재 서버 사이트에서 더 이상 사용할 수 없음을 클라이언트에 알리는 데에도 사용됩니다. 물론, 영구적으로 사용할 수 없는 모든 리소스를 '410 Gone'으로 표시해야 하는지 여부와 이 표시를 얼마나 오래 유지해야 하는지는 전적으로 서버 소유자에게 달려 있습니다. |
| 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 엔터티 헤더를 포함해야 합니다. 이 응답은 Multipart/byteranges를 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 Advanced Collections 초안에 정의되어 있지만 "WebDAV Sequence Collection Protocol"(RFC 3658)에는 나타나지 않습니다. |
| 426 |
클라이언트는 TLS/1.0으로 전환해야 합니다. (RFC 2817) |
| 449 |
Extension by Microsoft는 적절한 작업을 수행한 후 요청을 다시 시도해야 함을 나타냅니다. |
| 500 |
서버에 예상치 못한 상황이 발생하여 요청 처리를 완료할 수 없습니다. 일반적으로 이 문제는 서버의 프로그램 코드에 오류가 있을 때 발생합니다. |
| 501 |
서버가 현재 요청에 필요한 기능을 지원하지 않습니다. 서버가 요청된 메서드를 인식하지 못하고 리소스에 대한 요청을 지원할 수 없는 경우. |
| 502 |
게이트웨이 또는 프록시로 작동하는 서버가 요청을 수행하려고 할 때 업스트림 서버로부터 잘못된 응답을 받았습니다. |
| 503 |
일시적인 서버 점검이나 과부하로 인해 현재 서버에서 요청을 처리할 수 없습니다. 이 상태는 일시적이며 일정 시간이 지나면 복원됩니다. 지연이 예상되는 경우 응답에는 지연을 나타내는 Retry-After 헤더가 포함될 수 있습니다. 이 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) |
