| HTTP 상태 코드 | 상태 코드의 의미 |
|---|---|
| 100 | 클라이언트는 여전히 요청을 보내야 합니다. 이 임시 응답은 요청의 일부가 서버에 의해 수신되었으며 아직 거부되지 않았음을 클라이언트에 알리는 데 사용됩니다. 클라이언트는 요청의 나머지 부분을 계속 보내거나 요청이 완료되면 응답을 무시해야 합니다. 요청을 완료한 후 서버는 클라이언트에 최종 응답을 보내야 합니다. |
| 101 | 서버는 클라이언트의 요청을 이해하고 업그레이드 메시지 헤더를 통해 요청을 완료하기 위해 다른 프로토콜을 사용하도록 클라이언트에 알립니다. 이 응답의 마지막 빈 줄을 보낸 후 서버는 업그레이드 메시지 헤더에 정의된 프로토콜로 전환합니다. 새로운 프로토콜로 전환하는 것이 더 유리한 경우에만 유사한 절차를 수행해야 합니다. 예를 들어 최신 HTTP 버전으로 전환하면 이전 버전에 비해 이점이 있습니다. 또는 이러한 기능을 사용하여 리소스를 전송하려면 실시간 및 등시성 프로토콜로 전환하세요. |
| 102 | 처리가 계속되어야 함을 나타내는 WebDAV(RFC 2518)에 의해 확장된 상태 코드입니다. |
| 200 | 요청이 성공했습니다. 요청된 응답 헤더 또는 데이터 본문이 이 응답과 함께 반환됩니다. |
| 201 | 요청이 완료되고 요청을 기반으로 새 리소스가 생성되었으며 해당 URI가 Location 헤더와 함께 반환되었습니다. 필요한 리소스를 제때에 구축할 수 없는 경우 "202 Accepted"가 반환되어야 합니다. |
| 202 | 서버가 요청을 수락했지만 아직 처리하지 않았습니다. 요청이 거부되는 것처럼 결국에는 요청이 이행될 수도 있고 이행되지 않을 수도 있습니다. 비동기 작업의 경우 이 상태 코드를 보내는 것 외에는 편리한 방법이 없습니다. 202 상태 코드로 응답을 반환하는 목적은 서버가 다른 프로세스(예: 하루에 한 번만 실행되는 일괄 처리 기반 작업)의 요청을 수락할 수 있도록 하는 것입니다. 일괄 작업이 완료되었습니다. 처리 요청을 수락하고 202 상태 코드를 반환하는 응답은 반환된 엔터티에 처리의 현재 상태와 처리 상태 모니터 또는 상태 예측에 대한 포인터를 나타내는 정보를 포함해야 합니다. 작업이 완료되었습니다. |
| 203 | 서버가 요청을 성공적으로 처리했지만 원본 서버에서 유효한 결정적 집합이 아닌 로컬 또는 타사 복사본에서 엔터티 헤더 정보를 반환했습니다. 현재 정보는 원래 버전의 하위 집합이거나 상위 집합일 수 있습니다. 예를 들어 리소스에 대한 메타데이터를 포함하면 원본 서버가 메타데이터를 인식할 수 있습니다. 이 상태 코드를 사용할 필요는 없습니다. 이 상태 코드가 응답에 사용되지 않은 경우에만 200을 반환합니다. 상황은 괜찮습니다. |
| 204 | 서버가 요청을 성공적으로 처리했지만 엔터티 콘텐츠를 반환할 필요는 없으며 업데이트된 메타 정보를 반환하려고 합니다. 응답은 엔터티 헤더 형식으로 새로운 메타 정보나 업데이트된 메타 정보를 반환할 수 있습니다. 이러한 헤더가 있는 경우 요청된 변수와 일치해야 합니다. 클라이언트가 브라우저인 경우 새 메타 정보나 업데이트된 메타 정보를 사용자 브라우저의 활성 문서 보기에 적용해야 하는 경우에도 사용자 브라우저는 문서 보기를 변경하지 않고 요청한 페이지를 렌더링합니다. 204 Forbidden 응답에는 메시지 본문이 포함되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 205 | 서버가 요청을 성공적으로 처리했지만 아무것도 반환하지 않았습니다. 그러나 204 응답과 달리 이 상태 코드를 반환하는 응답에서는 요청자가 문서 보기를 재설정해야 합니다. 이 응답은 사용자가 다른 입력을 쉽게 시작할 수 있도록 사용자 입력을 수락한 후 즉시 양식을 재설정하는 데 주로 사용됩니다. 204 응답과 마찬가지로 응답에도 메시지 본문을 포함할 수 없으며 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 206 | 서버가 일부 GET 요청을 성공적으로 처리했습니다. FlashGet, Thunder 및 기타 HTTP 다운로드 도구는 이 응답을 사용하여 중단점 다시 시작을 구현하거나 동시 다운로드를 위해 대용량 파일을 여러 다운로드 세그먼트로 분할합니다. 요청에는 클라이언트가 원하는 콘텐츠 범위를 나타내는 Range 헤더가 포함되어야 하며, 요청 조건으로 If-Range를 포함할 수 있습니다. 응답에는 다음 헤더 필드가 포함되어야 합니다. Content-Range는 이 응답에서 반환된 콘텐츠 범위를 나타내는 데 사용됩니다. 멀티파트/바이트 범위 Content-Type이 포함된 멀티파트 다운로드의 경우 각 멀티파트 파트에는 해당 파트의 범위를 나타내는 Content-Range 필드가 포함되어야 합니다. Content-Length가 응답에 포함된 경우 해당 값은 반환된 콘텐츠 범위의 실제 바이트 수와 일치해야 합니다. 날짜 ETag 및/또는 콘텐츠 위치(동일한 요청이 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 사양에서는 이 자동 선택이 수행되는 방법을 지정하지 않습니다. 서버 자체에 이미 기본 피드백 옵션이 있는 경우 위치 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에 액세스합니다. URI. 원래 요청의 방법입니다. 서버가 클라이언트에게 기대하는 작업을 명확히 하기 위해 상태 코드 303 및 307을 추가했습니다. |
| 303 | 현재 요청에 해당하는 응답은 다른 URI에서 찾을 수 있으며 클라이언트는 해당 리소스에 액세스하려면 GET을 사용해야 합니다. 이 방법은 주로 스크립트 활성화 POST 요청의 출력을 새 리소스로 리디렉션할 수 있도록 하기 위해 존재합니다. 이 새 URI는 원래 리소스에 대한 대체 참조가 아닙니다. 또한 303 응답 캐싱을 비활성화합니다. 물론 두 번째 요청(리디렉션)도 캐시할 수 있습니다. 응답의 위치 필드에 새 URI가 반환되어야 합니다. HEAD 요청이 아닌 이상 응답 엔터티에는 새 URI에 대한 하이퍼링크와 간단한 설명이 포함되어야 합니다. 참고: HTTP/1.1 이전의 많은 브라우저는 303 상태를 올바르게 인식하지 못합니다. 이러한 브라우저와의 상호 작용에 관심이 있다면 302 상태 코드로 충분합니다. 이는 대부분의 브라우저가 위 사양의 303 응답을 처리할 때 클라이언트가 수행해야 하는 것과 정확히 동일하게 302 응답을 처리하기 때문입니다. |
| 304 | 클라이언트가 조건부 GET 요청을 보냈고, 요청이 승인되었으며, 문서 내용이 변경되지 않은 경우(마지막으로 액세스했거나 요청한 조건을 기반으로 한 이후) 서버는 이 상태 코드를 반환해야 합니다. 304 Forbidden 응답에는 메시지 본문이 포함되어 있으므로 항상 메시지 헤더 뒤의 첫 번째 빈 줄로 끝납니다. 응답에는 다음 헤더가 포함되어야 합니다. 날짜(이 서버에 시계가 없는 경우 제외). 시계 없는 서버도 이러한 규칙을 준수하는 경우 프록시 서버와 클라이언트는 수신된 응답 헤더에 날짜 필드(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 헤더가 포함되어 사용자에게 정보를 요청해야 합니다. 클라이언트는 적절한 인증 헤더를 사용하여 요청을 반복적으로 보낼 수 있습니다. 현재 요청에 이미 인증 인증서가 포함된 경우 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"으로 표시되어야 하지 않나요? 이 태그가 유지되는 기간은 전적으로 서버 소유자에게 달려 있습니다. |
| 411 | 서버는 Content-Length 헤더가 정의되지 않은 요청 수락을 거부합니다. 요청 메시지 본문의 길이를 나타내는 유효한 Content-Length 헤더를 추가한 후 클라이언트는 요청을 다시 보낼 수 있습니다. |
| 412 | 서버가 요청 헤더 필드를 확인하는 동안 해당 필수 구성 요소 중 하나 이상을 충족하지 못했습니다. 이 상태 코드를 사용하면 클라이언트는 리소스를 검색할 때 요청의 메타 정보(요청 헤더 필드 데이터)에 대한 전제 조건을 설정하여 요청 메서드가 필요한 것 이외의 리소스에 적용되는 것을 방지할 수 있습니다. . |
| 413 | 요청이 서버가 처리하려고 하거나 처리할 수 있는 것보다 큰 엔터티 데이터를 전송하기 때문에 서버가 현재 요청 처리를 거부하고 있습니다. 이 경우 서버는 클라이언트가 이 요청을 계속 보내는 것을 방지하기 위해 연결을 닫을 수 있습니다. 조건이 일시적인 경우 서버는 Retry-After 응답 헤더를 반환하여 나중에 재시도할 횟수를 클라이언트에 알려야 합니다. |
| 414 | 요청 URI가 서버가 해석할 수 있는 것보다 길기 때문에 서버가 요청 처리를 거부하고 있습니다. 이는 덜 일반적이지만 일반적으로 POST 메소드를 사용해야 했던 양식 제출이 이제 GET 메소드이고 쿼리 문자열(쿼리 문자열)이 너무 깁니다. 리디렉션 URI의 "블랙홀". 예를 들어 각 리디렉션은 이전 URI를 새 URI의 일부로 사용하므로 여러 번의 리디렉션 후에는 URI가 더 길어집니다. 클라이언트가 일부 서버에 보안 허점이 있는 서버를 공격하려고 합니다. 이 유형의 서버는 요청 URI를 읽고 조작하기 위해 고정 길이 버퍼를 사용합니다. post-GET 매개변수가 특정 값을 초과하면 버퍼 오버플로가 발생하고 임의의 코드가 실행될 수 있다[1]. 이러한 취약점이 없는 서버는 414 상태 코드를 반환해야 합니다. |
| 415 | 요청에 전송된 엔터티가 서버에서 지원하는 형식이 아니기 때문에 현재 요청된 메서드 및 요청된 리소스에 대한 요청이 거부되었습니다. |
| 416 | 요청에 Range 요청 헤더가 포함되어 있고 Range에 지정된 데이터 범위가 현재 리소스의 사용 가능한 범위와 일치하지 않으며 If-Range 요청 헤더가 요청에 정의되어 있지 않은 경우 서버는 416 상태 코드를 반환해야 합니다. Range가 바이트 범위를 사용하는 경우 이 상황은 요청에 의해 지정된 모든 데이터 범위의 첫 번째 바이트 위치가 현재 리소스의 길이를 초과함을 의미합니다. 또한 서버는 416 상태 코드를 반환하고 현재 리소스의 길이를 나타내는 Content-Range 엔터티 헤더를 포함해야 합니다. 이 응답은 또한 콘텐츠 유형으로 multipart/byteranges를 허용하지 않습니다. |
| 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 Serial Collections Protocol(RFC 3658)에는 없습니다. |
| 426 | 클라이언트는 TLS/1.0으로 전환해야 합니다. (RFC2817) |
| 449 | 적절한 조치를 취한 후 대리인 요청을 다시 시도하도록 Microsoft에서 강화했습니다. |
| 500 | 서버에 예상치 못한 상황이 발생하여 요청을 완료할 수 없습니다. 이 문제는 일반적으로 서버 프로그램 코드가 올바르지 않을 때 발생합니다. |
| 501 | 서버가 현재 요청에 필요한 기능을 지원하지 않습니다. 서버가 요청한 메소드를 인식하지 못해 리소스 요청을 지원할 수 없는 경우. |
| 502 | 게이트웨이 또는 프록시 역할을 하는 서버가 요청을 이행하는 동안 업스트림 서버로부터 잘못된 응답을 받았습니다. |
| 503 | 일시적인 서버 점검 또는 과부하로 인해 현재 서버에서 요청을 처리할 수 없습니다. 이 상태는 일시적이며 일정 시간이 지나면 정상으로 돌아옵니다. 지연을 추정할 수 있는 경우 응답에는 지연을 나타내는 Retry-After 헤더가 포함될 수 있습니다. 이 Retry-After 정보가 제공되지 않으면 클라이언트는 이를 500 응답으로 처리해야 합니다. 참고: 503 상태 코드가 있다고 해서 서버가 과부하되었을 때 사용해야 한다는 의미는 아닙니다. 일부 서버는 클라이언트 연결을 거부하려고 합니다. |
| 504 | 게이트웨이나 프록시 역할을 하는 서버가 요청을 이행하려고 하면 업스트림 서버(HTTP, FTP, LDAP 등 URI로 식별되는 서버)나 보조 서버(DNS, 등.). ). 빠르게. 참고: 일부 프록시 서버는 DNS 쿼리 시간이 초과되면 400 또는 500 오류를 반환합니다. |
| 505 | 서버가 요청에 사용된 HTTP 버전을 지원하지 않거나 지원을 거부합니다. 이는 서버가 클라이언트와 동일한 버전을 사용할 수 없거나 사용하기를 원하지 않음을 의미합니다. 응답에는 버전이 지원되지 않는 이유와 서버가 지원하는 프로토콜을 설명하는 엔터티가 포함되어야 합니다. |
| 506 | 내부 서버 구성 오류를 나타내기 위해 Transparent Content Negotiation 프로토콜(RFC 2295)에 의해 확장되었습니다. |
| 507 | 서버는 요청을 이행하는 데 필요한 것을 저장할 수 없습니다. 이 상태는 일시적인 것으로 간주됩니다. WebDAV(RFC 4918) |
| 509 | 서버가 대역폭 제한에 도달했습니다. 이는 공식적인 상태 코드는 아니지만 여전히 널리 사용됩니다. |
| 510 | 자원을 획득하는 데 필요한 전략이 충분하지 않습니다. (RFC2774) |
