팁: 빠른 검색을 위해 Ctrl+F를 사용하세요.| HTTP 상태 코드 | 상태 코드 의미 |
|---|---|
| 100 | 클라이언트는 요청을 계속 보내야 합니다. 이 임시 응답은 클라이언트에게 요청의 일부가 서버에 수신되었으며, 아직 거부되지 않았음을 알리기 위해 사용됩니다. 클라이언트는 요청의 나머지 부분을 계속 전송해야 하며, 이미 요청이 완료된 경우에는 이 응답을 무시해야 합니다. 서버는 요청이 완료된 후 클라이언트에게 최종 응답을 보내야 합니다. |
| 101 | 서버는 클라이언트의 요청을 이해했으며, Upgrade 헤더를 사용하여 클라이언트에게 요청을 완료하기 위해 다른 프로토콜로 전환하도록 알릴 것입니다. 이 응답의 마지막 빈 줄을 전송한 후, 서버는 Upgrade 헤더에 지정된 프로토콜로 전환합니다. 이러한 조치는 새로운 프로토콜로 전환하는 것이 분명한 이점을 제공할 때에만 취해져야 합니다. 예를 들어, 더 최신 버전의 HTTP로 전환하는 것이 이전 버전에 비해 장점이 있을 수 있으며, 실시간·동기식 프로토콜로 전환하는 것은 이러한 기능을 활용하는 리소스를 제공하는 데 유리할 수 있습니다. |
| 102 | WebDAV(RFC 2518)에서 확장된 상태 코드로, 요청 처리가 계속될 것임을 나타냅니다. |
| 200 | 요청이 성공적으로 처리되었으며, 요청한 응답 헤더나 본문이 이 응답과 함께 반환됩니다. |
| 201 | 요청이 성공적으로 처리되었으며, 요청에 따라 새로운 자원이 생성되었습니다. 해당 URI가 Location 헤더에 반환되었습니다. 필요한 자원을 적시에 제공할 수 없는 경우, 서버는 ‘202 Accepted’ 응답을 반환해야 합니다. |
| 202 | 서버는 요청을 수락했지만, 아직 처리되지 않았습니다. 거부될 수도 있듯이, 해당 요청은 최종적으로 실행될 수도 있고 그렇지 않을 수도 있습니다. 비동기 시나리오에서는 이 상태 코드를 전송하는 것만큼 이를 알리는 데 더 편리한 방법은 없습니다. 202 상태 코드를 반환하는 응답의 목적은, 클라이언트가 전체 배치 작업이 완료될 때까지 서버와 지속적인 연결을 유지할 필요 없이, 서버가 다른 프로세스(예: 하루에 한 번만 실행되는 배치 작업)에 대한 요청을 수락할 수 있도록 하는 데 있습니다. 처리 요청을 수락하고 202 상태 코드를 반환하는 응답은, 사용자가 작업이 완료되었는지 여부를 판단할 수 있도록, 응답 본문에 현재 처리 상태를 나타내는 정보와 더불어 처리 상태 모니터 또는 상태 예측 메커니즘에 대한 포인터를 포함해야 합니다. |
| 203 | 서버는 요청을 성공적으로 처리했지만, 반환된 엔터티 헤더 메타데이터는 원본 서버에서 유효한 결정적 집합을 구성하는 것이 아니라, 로컬 또는 타사 복사본에서 파생된 것입니다. 현재 정보는 원본 버전의 부분집합이거나 상위집합일 수 있습니다. 예를 들어, 리소스와 함께 제공되는 메타데이터는 원본 서버가 메타정보의 상위 집합을 유지할 수 있게 할 수 있습니다. 이 상태 코드를 사용하는 것은 필수적이지 않으며, 이 상태 코드를 사용하지 않는 응답이 그렇지 않으면 200 OK를 반환해야 하는 경우에만 적절합니다. |
| 204 | 서버는 요청을 성공적으로 처리했지만, 엔티티 콘텐츠를 반환할 필요가 없으며 업데이트된 메타데이터를 반환하길 원합니다. 응답에는 엔터티 헤더 형태로 새로운 또는 업데이트된 메타데이터가 포함될 수 있습니다. 이러한 헤더 필드가 존재하는 경우, 요청되는 변수와 일치해야 합니다. 클라이언트가 웹 브라우저인 경우, 사용자의 브라우저는 사양에 따라 브라우저의 활성 보기 내 문서에 새 메타데이터 또는 업데이트된 메타데이터가 적용되어야 한다고 규정되어 있더라도, 요청을 시작한 페이지를 문서 뷰에 어떠한 변경도 가하지 않은 채 그대로 유지해야 합니다. 204 응답은 메시지 본문을 포함할 수 없으므로, 항상 메시지 헤더 다음에 오는 첫 번째 빈 줄로 종료됩니다. |
| 205 | 서버가 요청을 성공적으로 처리했으며, 반환된 콘텐츠는 없습니다. 하지만 204 응답과 달리, 이 상태 코드를 반환하는 응답은 클라이언트에게 문서 뷰를 리셋하도록 요구합니다. 이 응답은 주로 사용자 입력 후 폼을 즉시 초기화하여, 사용자가 쉽게 다른 항목을 입력할 수 있도록 하는 데 사용됩니다. 204 응답과 마찬가지로, 이 응답은 메시지 본문을 포함해서는 안 되며, 메시지 헤더 다음에 오는 첫 번째 빈 줄로 종료되어야 합니다. |
| 206 | 서버가 부분 GET 요청을 성공적으로 처리했습니다. FlashGet 또는 Thunderbolt와 같은 HTTP 다운로드 도구는 이러한 응답을 사용하여 전송을 재개하거나 대규모 문서를 동시 다운로드를 위해 여러 다운로드 세그먼트로 분해합니다. 요청은 클라이언트가 원하는 콘텐츠 범위를 나타내기 위해 범위 헤더 정보를 포함해야 하며, 요청 조건으로서 If-Range를 포함할 수 있다. 응답에는 다음 헤더 필드가 포함되어야합니다. 이 응답에서 반환되는 콘텐츠의 범위를 나타내는 Content-Range; multipart/byteranges의 Content-Type이 포함 된 다중 세그먼트 다운로드인 경우 각 멀티 파트 세그먼트에는 이 세그먼트의 콘텐츠 범위를 나타내는 Content-Range 필드가 포함되어야합니다. 응답에 Content-Length가 포함되어 있으면 해당 값은 반환하는 콘텐츠 범위의 실제 바이트 수와 일치해야합니다. 동일한 요청이 200 응답을 반환해야 하는 경우 날짜 ETag 및/또는 Content-Location. 해당 값이 동일한 변수의 다른 이전 응답에 해당하는 값과 다를 수 있는 경우 Experes, Cache-Control 및/또는 Vary.이 응답 요청이 If-Range 강력한 캐시 검증을 사용하는 경우 이 응답에는 다른 엔티티 헤더가 포함되지 않아야 합니다. 이 응답의 요청이 If-Range 약한 캐시 검증을 사용한다면, 이 응답은 다른 엔티티 헤더를 포함하는 것이 금지된다. 이것은 캐시된 엔티티 콘텐츠와 업데이트된 엔티티 헤더 정보 사이의 불일치를 방지한다. 그렇지 않으면, 이 응답은 200 응답에서 반환되어야 하는 모든 엔티티 헤더 필드를 포함해야 한다. ETag 또는 최종 수정 헤더가 정확히 일치하지 않으면, 클라이언트 캐시는 206 응답에 의해 반환된 콘텐츠가 임의의 이전에 캐시된 콘텐츠와 결합되는 것을 허용하지 않아야 한다. 범위 및 콘텐츠 범위 헤더를 지원하지 않는 임의의 캐시는 206 응답에 의해 반환된 콘텐츠의 캐싱을 비활성화한다. |
| 207 | WebDAV(RFC 2518)에서 확장된 상태 코드로, 이어지는 메시지 본문이 XML 문서임을 나타냅니다. 이 XML 문서에는 이전의 하위 요청 수에 따라 각각의 개별 응답 코드가 포함될 수 있습니다. |
| 300 | 요청된 리소스는 각기 고유한 URI와 브라우저 기반 콘텐츠 협상 파라미터를 갖춘 여러 가지 대체 표현을 가지고 있습니다. 사용자 또는 브라우저는 리디렉션할 선호하는 URL을 독립적으로 선택할 수 있습니다. 이 요청이 HEAD 요청이 아닌 경우, 응답에는 리소스의 특성과 주소를 나열한 엔터티가 포함되어야 하며, 이를 통해 사용자나 브라우저는 가장 적합한 리다이렉트 URL을 선택할 수 있습니다. 이 엔터티의 형식은 Content-Type 헤더에 지정된 형식에 따라 결정됩니다. 브라우저는 응답 형식과 자체 기능을 기반으로 가장 적합한 선택을 자동으로 할 수 있습니다. 물론, RFC 2616 사양에는 이러한 자동 선택이 어떻게 수행되어야 하는지에 대해 명시되어 있지 않습니다. 서버에 이미 선호하는 리다이렉트 대상이 있는 경우, 해당 대상의 URI를 Location 헤더에 명시해야 합니다. 브라우저는 이 Location 값을 자동 리디렉션의 대상 URL로 사용할 수 있습니다. 또한, 이 응답은 특별히 다르게 명시되지 않는 한 캐시 가능합니다. |
| 301 | 요청한 리소스는 새로운 위치로 영구적으로 이동되었으며, 이 리소스에 대한 향후 모든 참조는 이 응답에 반환된 URI 중 하나를 사용해야 합니다. 가능하다면, 링크 편집 기능을 갖춘 클라이언트는 요청한 URL을 서버에서 반환한 URL로 자동으로 업데이트해야 합니다. 별도로 명시되지 않는 한, 이 응답도 캐시할 수 있습니다. 새로운 영구 URI는 응답의 Location 헤더에 반환되어야 합니다. HEAD 요청이 아닌 경우, 응답 본문에는 새로운 URI로 연결되는 하이퍼링크와 간단한 설명이 포함되어야 합니다. 이 요청이 GET 또는 HEAD 요청이 아니라면, 브라우저는 사용자가 이를 확인하지 않는 한 자동 리디렉션을 차단합니다. 이는 요청의 조건이 변경될 수 있기 때문입니다. 참고: HTTP/1.0 프로토콜을 사용하는 일부 브라우저에서는, 보낸 POST 요청에 301 응답이 반환될 경우, 이후의 리다이렉트된 요청이 GET 요청으로 변경됩니다. |
| 302 | 요청된 리소스는 현재 임시로 다른 URI에서 제공되고 있습니다. 이 리디렉션은 임시이므로 클라이언트는 이후 요청을 계속해서 원래 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) 응답은 메시지 본문을 포함하는 것이 금지되며, 메시지 헤더 다음에 항상 제 1 빈 라인으로 종료된다. 응답에는 다음 헤더 정보가 포함되어야 합니다. 서버에 클록이 없는 경우 날짜. 클럭이없는 서버도 이러한 규칙을 준수하면 프록시 서버와 클라이언트가 수신 된 응답 헤더 (RFC 2068 에 명시된대로) 에 날짜 필드를 추가 할 수 있으며 캐싱 메커니즘이 정상적으로 작동합니다. 동일한 요청이 200 응답을 반환해야하는 경우 ETag 및/또는 Content-Location. 해당 값이 동일한 변수의 다른 이전 응답에 해당하는 값과 다를 수 있는 경우 Experes, Cache-Control 및/또는 Vary.이 응답 요청이 강력한 캐시 검증을 사용하는 경우 이 응답에는 다른 엔티티 헤더가 없어야합니다. 그렇지 않으면 (예: 조건부 GET 요청이 약한 캐시 유효성 검사를 사용함) 이 응답은 다른 엔티티 헤더의 포함을 금지합니다. 이는 캐시 된 엔티티 콘텐츠와 업데이트된 엔티티 헤더 정보 간의 불일치를 방지합니다. 만약 304 응답이 엔티티가 현재 캐싱되지 않았다는 것을 나타내면, 캐시 시스템은 응답을 무시하고 제약을 포함하지 않는 요청을 반복적으로 전송해야 한다. 캐시 엔트리에 대한 업데이트를 요구하는 304 응답이 수신되면, 캐시 시스템은 응답에서 업데이트된 모든 필드들의 값들을 반영하기 위해 전체 엔트리를 업데이트해야 한다. |
| 305 | 요청된 리소스는 지정된 프록시를 통해서만 접근할 수 있습니다. 위치 필드에는 지정된 프록시의 URI가 포함됩니다. 수신자는 해당 리소스에 접근하기 위해 이 프록시를 통해 별도의 요청을 다시 보내야 합니다. 305 응답은 오리진 서버만 생성할 수 있습니다. 참고: RFC 2068은 305 응답이 단일 요청을 리다이렉트하기 위한 것이며 오리진 서버에 의해만 생성될 수 있다고 명시하지 않습니다. 이러한 제한을 무시하면 심각한 보안 사고가 발생할 수 있습니다. |
| 306 | 규격의 최신 버전에서는 306 상태 코드가 더 이상 사용되지 않습니다. |
| 307 | 요청된 리소스는 현재 임시로 다른 URI에서 제공되고 있습니다. 이 리디렉션은 임시이므로 클라이언트는 이후 요청을 계속해서 원래 URI로 보내야 합니다. 이 응답은 Cache-Control 또는 Expires 헤더에 명시적으로 지정된 경우에만 캐시될 수 있습니다. 새로운 임시 URI는 응답의 Location 헤더에 반환되어야 합니다. HEAD 요청이 아닌 경우, 응답 본문에는 새로운 URI로 연결되는 하이퍼링크와 간단한 설명이 포함되어야 합니다. 일부 브라우저는 307 응답을 인식하지 못하므로, 사용자가 상황을 이해하고 새 URI로 요청을 발행할 수 있도록 위의 필수 정보를 포함해야 합니다. 요청이 GET 또는 HEAD 요청이 아닌 경우, 브라우저는 사용자가 명시적으로 확인하지 않는 한 리다이렉트를 자동으로 따르면 안 됩니다. 그 이유는 리다이렉트로 인해 요청의 조건이 변경될 수 있기 때문입니다. |
| 400 | 1, 의미 오류, 현재 요청은 서버에 의해 이해 될 수 없습니다. 수정하지 않는 한 클라이언트는이 요청을 반복적으로 제출해서는 안됩니다. 2. 요청 매개 변수가 잘못되었습니다. |
| 401 | 현재 요청은 사용자 인증이 필요합니다. 응답에는 요청된 리소스에 적용되는 WWW-Authenticate 헤더 필드가 포함되어야 하며, 이는 사용자에게 자격 증명을 입력하도록 요구합니다. 클라이언트는 유효한 Authorization 헤더를 포함하는 요청을 반복적으로 제출할 수 있습니다. 현재 요청에 이미 Authorization 헤더가 포함되어 있는 경우, 401 응답은 서버의 인증 프로세스가 해당 자격 증명을 거부했음을 나타냅니다. 401 응답에 이전 응답과 동일한 인증 챌린지가 포함되어 있고, 브라우저가 이미 적어도 한 번 이상 인증을 시도한 경우, 브라우저는 관련 진단 정보를 포함할 수 있으므로 사용자에게 해당 응답의 엔터티 본문을 표시해야 합니다. RFC 2617을 참조하십시오. |
| 402 | 이 상태 코드는 향후 필요에 대비하여 예약되어 있습니다. |
| 403 | 서버는 요청을 이해했지만 이를 실행하는 것을 거부합니다. 401 응답과 달리, 인증으로 문제를 해결할 수 없으며, 이 요청을 다시 시도해서는 안 됩니다. 이 요청이 HEAD 요청이 아니며, 서버가 요청을 완료할 수 없는 이유를 설명하고자 하는 경우, 거부 사유를 메시지 본문에 기재해야 합니다. 물론, 서버는 클라이언트가 어떠한 정보도 받기를 원하지 않는 경우 404 응답을 반환할 수도 있습니다. |
| 404 | 요청 실패: 요청한 자원이 서버에서 찾을 수 없습니다. 이 상태가 일시적인지 영구적인지 나타내는 정보는 없습니다. 서버가 해당 상황을 인지하고 있다면, 410 상태 코드를 사용하여 이전 리소스가 특정 내부 구성 문제로 인해 영구적으로 이용할 수 없으며, 리디렉션할 수 있는 대체 URL도 존재하지 않는다는 점을 나타내야 합니다. 404 상태 코드는 서버가 요청이 거부된 구체적인 이유를 공개하고 싶지 않거나, 다른 적절한 응답을 제공할 수 없는 경우에 널리 사용됩니다. |
| 405 | 요청 라인에 지정된 요청 메서드는 요청한 리소스에서 허용되지 않습니다. 응답에는 현재 리소스가 지원하는 요청 메서드를 나열한 Allow 헤더가 포함되어야 합니다. PUT 및 DELETE 메서드는 서버 리소스에 대한 쓰기 작업을 수행하므로, 대부분의 웹 서버는 이들 요청 메서드를 지원하지 않거나 기본적으로 이를 허용하지 않습니다. 따라서, 이러한 요청은 405 Method Not Allowed 오류를 반환합니다. |
| 406 | 요청된 리소스의 콘텐츠 특성이 요청 헤더에 지정된 조건을 충족하지 않으므로 응답 본문을 생성할 수 없습니다. 이 요청이 HEAD 요청이 아닌 경우, 응답에는 사용자나 브라우저가 그중에서 가장 적합한 것을 선택할 수 있도록 주소와 엔터티 특성의 목록을 제공하는 엔터티가 포함되어야 합니다. 엔터티의 형식은 Content-Type 헤더에 지정된 미디어 타입에 의해 결정됩니다. 브라우저는 형식과 자체 기능을 기반으로 스스로 최선의 선택을 할 수 있습니다. 그러나 이 표준은 이러한 자동 선택을 수행하기 위한 어떠한 기준도 정의하고 있지 않습니다. |
| 407 | 401 응답과 유사하지만, 클라이언트가 프록시 서버에 인증해야 한다는 점만 다릅니다. 프록시 서버는 인증을 시작하기 위해 Proxy-Authenticate 헤더를 반환해야 합니다. 클라이언트는 인증을 위해 Proxy-Authorization 헤더를 반환할 수 있습니다. RFC 2617 을 참조하십시오. |
| 408 | 요청 시간이 초과되었습니다. 클라이언트가 서버의 구성된 시간 초과 기간 내에 요청 전송을 완료하지 못했습니다. 클라이언트는 아무런 변경 없이 언제든지 이 요청을 다시 제출할 수 있습니다. |
| 409 | 요청한 리소스의 현재 상태와 충돌이 있어 요청을 완료할 수 없습니다. 이 코드는 사용자가 갈등을 해결할 수 있다고 판단되며, 새로운 요청을 다시 제출할 경우에만 사용할 수 있습니다. 응답에는 사용자가 충돌의 원인을 파악할 수 있도록 충분한 정보가 포함되어야 합니다. 충돌은 일반적으로 PUT 요청을 처리하는 동안 발생합니다. 예를 들어, 버전 검사를 사용하는 환경에서 특정 리소스를 수정하는 PUT 요청에 첨부된 버전 정보가 이전의 (타사) 요청의 버전 정보와 충돌하는 경우, 서버는 409 Conflict 상태 코드를 반환하여 클라이언트에게 해당 요청을 완료할 수 없다는 사실을 알려야 합니다. 이 시점에서 응답 본문에는 서로 충돌하는 두 버전을 비교한 차이점(디프)이 포함될 가능성이 높으며, 이를 통해 사용자는 병합되고 업데이트된 버전을 다시 제출할 수 있습니다. |
| 410 | 요청한 자원은 더 이상 서버에 존재하지 않으며, 알려진 전달 주소도 없습니다. 이 상황은 상시적인 것으로 간주되어야 합니다. 가능하다면, 링크 편집 기능을 갖춘 고객사는 사용자의 동의를 얻은 후 이 URL을 가리키는 모든 참조를 제거해야 합니다. 서버가 해당 조건이 영구적인지 여부를 알 수 없거나 신뢰할 수 있는 방식으로 판단할 수 없는 경우, 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 Status Code를 반환해야 합니다. Range 헤더가 바이트 범위를 사용하는 경우, 요청된 모든 범위의 첫 번째 바이트의 바이트 오프셋이 현재 리소스의 길이를 초과하면 이와 같은 상황이 발생합니다. 서버는 416 Range Not Satisfiable 상태 코드와 함께 Content-Range 엔터티 헤더를 포함하여 리소스의 현재 길이를 나타내야 합니다. 이 응답은 Content-Type으로 multipart/byteranges를 사용하는 것도 금지되어 있습니다. |
| 417 | Expect 요청 헤더에 지정된 기대 조건을 서버가 충족할 수 없거나, 해당 서버가 프록시이며 현재 경로의 다음 홉에서 Expect 값이 충족될 수 없다는 명확한 증거가 있는 경우입니다. |
| 421 | 현재 클라이언트의 IP 주소에서 서버로 설정된 연결 수가 서버의 최대 허용 한도를 초과했습니다. 일반적으로 여기에서 말하는 IP 주소는 서버가 볼 때의 클라이언트 주소(예: 사용자의 게이트웨이 또는 프록시 서버 주소)를 의미합니다. 이 시나리오에서는 연결 수의 계산에 여러 최종 사용자가 관여할 수 있습니다. |
| 422 | 현재 클라이언트의 IP 주소에서 서버로 설정된 연결 수가 서버의 최대 허용 한도를 초과했습니다. 일반적으로 여기에서 말하는 IP 주소는 서버가 볼 때의 클라이언트 주소(예: 사용자의 게이트웨이 또는 프록시 서버 주소)를 의미합니다. 이 시나리오에서는 연결 수의 계산에 여러 최종 사용자가 관여할 수 있습니다. |
| 422 | 요청 형식은 올바르지만, 의미적 오류로 인해 처리할 수 없습니다. (RFC 4918 WebDAV) 423 잠김 현재 리소스는 잠겨 있습니다. (RFC 4918 웹DAV) |
| 424 | PROPPATCH와 같은 이전 요청에서 발생한 오류로 인해 현재 요청이 실패했습니다. (RFC 4918 WebDAV) |
| 425 | 이는 WebDAV 고급 컬렉션 초안에 정의되어 있지만, WebDAV 순서 지정 컬렉션 프로토콜(RFC 3658)에는 포함되어 있지 않습니다. |
| 426 | 클라이언트는 TLS 1.0으로 전환해야 합니다. (RFC 2817) |
| 449 | Microsoft에서 확장한 이 상태 코드는 적절한 조치를 취한 후 요청을 다시 시도해야 함을 나타냅니다. |
| 500 | 서버는 요청을 완료할 수 없게 만드는 예기치 않은 상태를 발견했습니다. 일반적으로 이 문제는 서버 코드에 오류가 있을 때 발생합니다. |
| 501 | 서버가 현재 요청에 필요한 기능을 지원하지 않습니다. 서버가 요청 메서드를 인식하지 못하고 어떤 자원에 대한 요청도 지원할 수 없는 경우. |
| 502 | 게이트웨이나 프록시 역할을 하는 서버가 요청을 처리하려고 시도하는 동안 업스트림 서버로부터 유효하지 않은 응답을 받았습니다. |
| 503 | 서버는 현재 임시 서버 유지 보수 또는 과부하로 인해 요청을 처리할 수 없습니다. 이 상황은 일시적이며 일정 기간 후에 복원됩니다. 지연 시간이 예상될 수 있다면, 응답은 지연 시간을 표시하기 위해 재시도-후 헤더를 포함할 수 있다. 이 재시도-후 정보가 제공되지 않으면 클라이언트는 500 응답과 동일한 방식으로 처리해야합니다. 참고: 503 상태 코드가 존재한다고해서 오버로드되었을 때 서버가 사용해야 함을 의미하지는 않습니다. 일부 서버는 단순히 클라이언트 연결을 거부하려고합니다. |
| 504 | 게이트웨이 또는 프록시 역할을 하는 서버가 요청을 처리하려고 할 때, 업스트림 서버(예: HTTP, FTP, LDAP 서버 등 URI로 식별되는 서버)나 보조 서버(예: DNS 서버)로부터 적시에 응답을 받지 못하면 발생합니다. 참고: 일부 프록시 서버는 DNS 쿼리 시간이 초과되면 400 또는 500 오류가 반환됩니다. |
| 505 | 서버가 요청에 사용된 HTTP 버전을 지원하지 않거나 지원을 거부합니다. 이는 서버가 클라이언트와 동일한 프로토콜 버전을 사용할 수 없거나 사용하지 않으려 한다는 것을 나타냅니다. 응답에는 해당 버전이 지원되지 않는 이유와 서버가 지원하는 프로토콜을 설명하는 엔터티가 포함되어야 합니다. |
| 506 | 투명한 콘텐츠 협상 프로토콜(RFC 2295)에 의해 확장된 이 상태 코드는 서버에 내부 구성 오류가 있음을 나타냅니다: 요청된 변형에 해당하는 리소스가 투명한 콘텐츠 협상에서 스스로를 사용하도록 구성되어 있으며, 따라서 협상 과정의 적절한 대상이 아닙니다. |
| 507 | 서버가 요청을 완료하는 데 필요한 콘텐츠를 저장할 수 없습니다. 이 상황은 일시적인 것으로 간주됩니다. 웹다브 (RFC 4918) |
| 509 | 서버가 대역폭 한계에 도달했습니다. 이것은 공식 상태 코드는 아니지만 여전히 널리 사용됩니다. |
| 510 | 리소스에 접근하는 데 필요한 정책이 충족되지 않았습니다. (RFC 2774) |
친구 링크:iCMS