| HTTP 상태 코드 | 상태 코드 의미 |
|---|
| 100 | 고객 측은 계속 요청을 보내야 합니다. 이 일시적인 응답은 고객 측이 요청 중 일부를 서버가 수신하고 거부하지 않았음을 알리기 위해 사용됩니다. 고객 측은 나머지 요청을 보내거나 요청이 완료되었을 경우 응답을 무시해야 합니다. 서버는 요청이 완료된 후 고객 측에 최종 응답을 보내어야 합니다. |
| 101 | 서버는 클라이언트의 요청을 이해했으며, 클라이언트 측을 통해 Upgrade 헤더를 통해 다른 프로토콜을 사용하여 요청을 완료하도록 알릴 것입니다. 응답의 마지막 공백 줄을 보낼 때까지 서버는 Upgrade 헤더에 정의된 프로토콜로 전환할 것입니다. 새로운 프로토콜로 전환하는 것이 더 유익할 때에만 이러한 조치를 취해야 합니다. 예를 들어, 새로운 HTTP 버전으로 전환하는 것은 오래된 버전보다 장점이 있거나, 실제}}-시간과 동기 프로토콜을 통해 이러한 기능을 활용하는 자원을 전달합니다. |
| 102 | WebDAV(RFC)에 확장된 상태 코드 2518)는 처리가 계속될 것을 나타냅니다. |
| 200. | 요청이 성공했으며, 원하는 응답 헤더나 데이터 본문이 응답과 함께 반환됩니다. |
| 201 | 요청이 완료되었으며, 요청의 요구 사항에 따라 새로운 자원이 생성되었으며, 그 URI는 Location 헤더와 함께 반환되었습니다. 필요한 자원이 시간에 따라 생성되지 않을 경우, '202 반환되어야 합니다. |
| 202 | 서버는 요청을 받았지만 아직 처리하지 않았습니다. 거부될 수도 있지만, 결국 실행될 수도 있고 아닐 수도 있습니다. 비동기 작업의 경우, 이 상태 코드를 보내는 것이 가장 편리한 방법입니다. 'Accepted'를 반환하는 목적은 202 상태 코드 응답은 서버가 다른 프로세스(예: 배치)로부터 요청을 받을 수 있도록 허용합니다.-일일로 수행되는 기본 작업(서버에 클라이언트 측이 연결되지 않아도 배치 작업이 완료될 때까지 기다리지 않아도 됨)에 응답하여 처리 요청을 받고 반환하는 202 상태 코드, 반환된 엔티티는 과정의 현재 상태를 나타내는 정보와 과정 상태 모니터나 상태 예측에 대한 포인터를 포함해야 하며, 사용자가 작업이 완료되었는지 평가할 수 있도록 해야 합니다. |
| 203 | 서버가 요청을 성공적으로 처리했지만, 반환된 엔티티 헤더 메타 정보는 원래 서버에서 유효한 결정적인 집합이 아니라, 로컬이나 제3자-파티 복사본. 현재 정보는 원본 버전의 부분 집합 또는 전체 집합일 수 있습니다. 예를 들어, 자원을 포함한 메타데이터는 원래 서버가 메타 슈퍼를 알 수 있게 합니다. 이 상태 코드를 사용하는 것은 필요하지 않으며, 응답이 반환된 경우에만 적절합니다. 200 OK 이 상태 코드 없이. |
| 204 | 서버가 요청을 성공적으로 처리했지만, 물리적인 내용을 반환할 필요가 없으며, 업데이트된 메타 정보를 반환하고자 합니다. 응답은 엔티티 헤더의 형태로, 새로운 또는 업데이트된 메타 정보를 반환할 수 있습니다. 이 헤더 정보가 존재하면, 요청된 변수와 일치해야 합니다. 클라이언트 측이 브라우저라면, 사용자의 브라우저는 요청을 보낸 페이지를 문서 뷰를 변경하지 않고 유지해야 합니다. 새로운 또는 업데이트된 메타 정보가 사용자 브라우저의 활성 뷰에 적용되어야 한다면 그에 따라야 합니다. 그래서 204 응답은 메시지 본문을 포함하지 못하며, 항상 헤더 뒤의 첫 번째 빈 줄로 끝납니다. |
| 205 | 서버가 요청을 성공적으로 처리하고 아무것도 반환하지 않았습니다. 하지만 다른 것과는 달리 204 응답, 이 상태 코드를 반환하는 응답은 요청자가 문서 뷰를 재설정해야 하는 응답입니다. 이 응답은 주로 사용자 입력을 받은 후 즉시 양식을 재설정하여 사용자가 다른 입력을 쉽게 시작할 수 있도록 사용됩니다. 그리고 그 다음에 204 response, this response is also prohibited from including any message body and ends with the first blank line after the header. |
| 206 | The server has successfully processed part of the GET request. HTTP download tools like FlashGet or Xunlei use this type of response to implement a breakpoint continuation or to break up a large document into multiple download segments to download simultaneously. The request must contain a Range header to indicate the range of content the client side wants, and may include If-response를 포함할 수 있습니다. 이 응답은 메시지 본문을 포함할 수 없으며 헤더 이후 첫 번째 공백 줄로 끝납니다.-서버는 GET 요청의 일부를 성공적으로 처리했습니다. FlashGet이나 Xunlei와 같은 HTTP 다운로드 도구는 이러한 유형의 응답을 사용하여 중지 점 지속 또는 대형 문서를 여러 다운로드 구간으로 나누어 동시 다운로드를 구현합니다. 요청은 클라이언트 측이 원하는 내용 범위를 나타내는 Range 헤더를 포함해야 하며, If-Range를 요청 조건으로 사용하면, 응답은 다음 헤더 필드를 포함해야 합니다: Content-Range를 통해 이 응답에서 반환된 내용 범위를 나타내는 데 사용됩니다; 만약 이 응답이 다중/구간 다운로드를 Content-Type multipart-byteranges를 포함하면, 각 multipart 구간은 Content/또는 Content-Location, 같은 요청이 같은 응답을 반환해야 하는 경우. 200 응답. Expires, Cache-Control, 그리고/Range 필드를 통해 이 구간의 내용 범위를 나타내는 데 사용됩니다. 응답이 Content-Length를 사용하면, 그 값은 반환하는 내용 범위의 실제 바이트 수와 일치해야 합니다. Date ETag 및-or Vary를 사용하면, 그 값이 다른 응답과 같은 변수에 대한 값과 다를 수 있습니다. 만약 이 응답 요청이 If 2Range week cache validation이면, 이 응답은 다른 엔티티 헤더를 포함하지 않아야 합니다; 만약 이 응답 요청이 If-Range week cache validation이면, 이 응답은 다른 엔티티 헤더를 포함하지 않아야 합니다; 이는 캐싱된 엔티티 내용과 업데이트된 엔티티 헤더 정보 간의 불일치를 피합니다. 그렇지 않으면, 이 응답은 Range 강력한 캐싱��표화에서 반환해야 할 모든 엔티티 헤더 필드를 포함해야 합니다. 206 00 응답에서 반환된 내용을 결합할 수 없도록 해야 합니다. ETag 또는 Last-Range 헤더는 응답으로 반환된 내용을 이전에 캐싱된 내용으로부터 캐싱할 수 없습니다. Range와 Content Modified 헤더가 정확하게 일치하지 않는 경우, 클라이언트 측 캐시는 응답으로 반환된 내용을 결합할 수 없도록 해야 합니다. 206 응답. |
| 207 | WebDAV (RFC)에 확장된 상태 코드 2518)는 이후 메시지의 본문이 XML 메시지로 되어 있으며, 이전 서브 요청의 수에 따라 여러 독립적인 응답 코드를 포함할 수 있습니다.-요청. |
| 300 | 요청한 자원은 다양한 피드백 옵션을 가지고 있으며, 각 옵션은 자신의 특정 주소와 브라우저 요청.-네고 정보. 사용자나 브라우저는 리디렉션에 대한 선호하는 주소를 선택할 수 있습니다. HEAD 요청이 아니라면, 응답은 사용자나 브라우저가 가장 적합한 리디렉션 주소를 선택할 수 있는 자원 특성과 주소 목록을 포함하는 엔티티를 포함해야 합니다. 이 엔티티의 형식은 Content-형식. 브라우저는 응답의 형식과 브라우저 자체의 기능을 기반으로 가장 적합한 선택을 자동으로 만들 수 있습니다. 물론, RFC가 제공하는 2616 서버 자체가 선호하는 피드백 선택을 이미 가지고 있다면, 피드백의 URI는 Location에 명시되어야 합니다. 브라우저는 이 Location 값을 자동 리디렉션의 주소로 사용할 수 있습니다. 또한, 기타가 명시되지 않는 한, 응답은 캐시 가능합니다. |
| 301 | 요청한 자원은 영구적으로 새 위치로 이동되었습니다. 이 자원에 대한 향후 참조는 이 응답으로부터 반환된 여러 URI 중 하나를 사용해야 합니다. 가능하다면, 링크 편집 기능을 갖춘 클라이언트는 서버로부터 반환된 주소로 요청된 주소를 자동으로 변경해야 합니다. 기타가 명시되지 않는 한, 이 응답은 캐시 가능합니다. 새로운 영구 URI는 응답의 Location 필드에 반환되어야 합니다. HEAD 요청이 아니라면, 응답 엔티티는 새 URI로 이동하는 히퍼링크와 간단한 설명을 포함해야 합니다. GET이나 HEAD 요청이 아니라면, 사용자가 확인하지 않은 경우 사용자 또는 브라우저는 자동으로 리디렉션할 수 없습니다. 요청 조건이 변경될 수 있습니다. 주의: 일부 브라우저는 HTTP 스펙ifikation이 이러한 자동 선택이 어떻게 수행되어야 하는지 명시하지 않습니다./1.0 프로토콜에서 POST 요청을 보내고 새로운 URI를 받을 때 301 응답 후, 이어지는 리디렉션 요청은 GET으로 됩니다. |
| 302 | 요청된 자원은 지금부터 다른 URI에서 요청에 응답하고 있습니다. 이러한 리디렉션이 일시적이므로, 클라이언트 측은 향후 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache에 지정된 경우에만 캐시 가능합니다.-제어나 Expires를 처리합니다. 새로운 일시적인 URI는 응답의 Location 필드에 반환되어야 합니다. HEAD 요청이 아니라면, 응답 엔티티는 새로운 URI에 대한 히퍼링크와 간단한 설명을 포함해야 합니다. GET이나 HEAD 요청이 아니라면, 사용자가 확인하지 않은 경우에만 자동 리디렉션을 금지합니다. 요청 조건이 변경될 수 있으므로 주의하세요:RFC 1945 및 2068 지정된 사양은 클라이언트 측이 리디렉션할 때 요청 메서드를 변경할 수 없도록 합니다. 많은 기존 브라우저는 RFC 302 응답을 303 응답을 GET으로 사용하여 지정된 URI에 접근하도록 하여, 원래 요청 메서드를 무시합니다. 상태 코드 303 그리고 307 서버가 클라이언트 측으로부터 기대하는 것을 명확히 하기 위해 추가되었습니다. |
| 303 | 현재 요청에 대한 응답은 다른 URI에 있으며, 클라이언트 측은 해당 자원에 대한 GET 접근을 가져야 합니다. 이 메서드는 주로 스크립트-POST 요청 출력이 새로운 자원으로 전송되도록 활성화되었습니다. 이 새로운 URI는 원래 자원에 대한 대체 참조가 아닙니다. 또한, 303 응답은 캐시될 수 없습니다. 물론, 두 번째 요청(리디렉션)은 캐시될 수 있습니다. 새 URI는 응답의 Location 필드에 반환되어야 합니다. HEAD 요청이 아니라면, 응답 엔티티는 새 URI에 대한 하이퍼링크와 간단한 설명을 포함해야 합니다. 주의: HTTP 이전의 많은 브라우저는/1.1 응답을 이해하지 못하면 303 브라우저와의 상호작용을 고려해야 한다면, 302 상태 코드만 충분하다, 대부분의 브라우저는 상태를 올바르게 처리합니다. 302 응답을 위와 같은 요구 사항에 따라 처리해야 합니다. 303 응답. |
| 304 | 클라이언트 측이 조건부 GET 요청을 보내고, 요청이 허용되었으며, 문서의 내용이 변경되지 않았다면 (마지막 방문 이후 또는 요청 조건에 따라), 서버는 이 상태 코드를 반환해야 합니다. 304 메시지 본체를 포함할 수 없게 되어, 항상 헤더 다음의 첫 번째 공백 줄로 끝내야 합니다. 응답은 다음 헤더 정보를 포함해야 합니다: Date, 이 서버가 시계가 없는 경우는 제외.
서버가 시계가 없더라도 이 규칙을 따르면, 프록시 서버와 클라이언트 측은 RFC에 따라 수신된 응답 헤더에 Date 필드를 추가할 수 있습니다 (예: RFC 2068), 그리고 캐싱 메커니즘은 원활하게 작동합니다. ETag 및/또는 Content-Location, 같은 요청이 같은 응답을 반환해야 하는 경우. 200 응답. Expires, Cache-Control, 그리고/Vary, 그 값이 이전에 동일한 변수에 대한 다른 응답과 다를 수 있는 경우.
이 응답 요청이 강력한 캐시 검증을 사용하면, 이 응답은 다른 엔티티 헤더를 포함할 수 없어야 합니다; 그렇지 않으면 (예를 들어, 조건부 GET 요청이 약한 캐시 검증을 사용하는 경우), 이 응답은 다른 엔티티 헤더를 포함할 수 없게 되며, 이는 캐시된 엔티티 내용과 업데이트된 엔티티 헤더 정보 간의 불일치를 피합니다. 만약 304 응답이 엔티티가 현재 캐시되어 있지 않음을 나타내면, 캐시 시스템은 응답을 무시하고 제한 없이 반복적으로 요청을 보내야 합니다.
만약 304 응답이 캐시된 항목을 업데이트하려면, 캐시 시스템은 응답에서 모든 필드의 값이 업데이트된 전체 항목을 업데이트해야 합니다. |
| 305 | 요청한 자원은 지정된 프록시를 통해 접근해야 합니다. 지정된 프록시의 URI 정보는 Location 필드에 제공됩니다. 수신자는 이 프록시를 통해 해당 자원에 접근하기 위해 별도의 요청을 반복적으로 보내야 합니다. 원래 서버만이 설정할 수 있습니다 305 응답. 주의: 명시적인 305 RFC에서의 응답 2068 단일 요청을 재정향하려면, 원래 서버에서만 설정할 수 있습니다. 이 제한을 무시하면 심각한 보안 문제가 발생할 수 있습니다. |
| 306 | 규격의 최신 버전에서는 306 상태 코드는 더 이상 사용되지 않습니다. |
| 307 | 요청한 자원은 지금 일시적으로 다른 URI에서 요청에 응답하고 있습니다. 이러한 재정향은 일시적이므로, 클라이언트 측은 미래의 요청을 원래 주소로 계속 보내야 합니다. 이 응답은 Cache 필드에서 지정된 경우에만 캐시할 수 있습니다.-제어나 만료일. 새 일시적인 URI는 응답의 Location 필드에 반환되어야 합니다. HEAD 요청이 아니라면, 응답 엔티티는 새 URI로 가는 하이퍼링크와 간단한 설명을 포함해야 합니다. 일부 브라우저는 이를 인식하지 않을 수 있습니다. 307 응답에서, 사용자가 이해하고 새 URI에 접근할 수 있도록 위의 정보를 추가해야 합니다.
이 것이 GET이나 HEAD 요청이 아니라면, 사용자가 확인하지 않으면 브라우저는 자동 재정향을 금지합니다. 요청 조건이 변경될 수 있기 때문입니다. |
| 400 | 1의미가 잘못되었으며, 현재 요청은 서버에 의해 이해될 수 없습니다. 변경되지 않았다면, 클라이언트 측은 요청을 반복적으로 제출하지 않아야 합니다. 2요청 매개변수가 잘못되었습니다. |
| 401 | 현재 요청은 사용자 인증이 필요합니다. 응답은 반드시 WWW를 포함해야 합니다.-요청된 리소스에 대한 인증 헤더를 사용하여 사용자에게 정보를 요청합니다. 클라이언트 측은 적절한 인증 헤더 정보를 포함한 요청을 다시 제출할 수 있습니다. 현재 요청이 이미 인증서를 포함하고 있다면, 401 응답은 서버가 해당 인증서를 거부했음을 나타냅니다. 401 응답이 이전 응답과 같은 인증 쿼리를 포함하고, 브라우저가 최소한 한 번 인증을 시도했으면, 브라우저는 응답에 포함된 엔티티 정보를 사용자에게 표시해야 합니다. 이 엔티티 정보는 관련 진단 정보를 포함할 수 있습니다. RFC를 참조하세요. 2617. |
| 402 | 이 상태 코드는 가능한 미래의 요구 사항을 위해 예약되었습니다. |
| 403 | 서버는 요청을 이해했지만 실행을 거부했습니다. 401 응답이 있으며, 인증은 도움이 되지 않으며 요청을 반복하지 않아야 합니다. 이가 HEAD 요청이 아니고, 서버가 요청이 왜 실행되지 않을 수 없는지 설명할 수 있도록 하고 싶다면, 거부 이유는 엔티티 내에 설명되어야 합니다. 물론, 서버는 또한 다른 응답을 반환할 수도 있습니다. 404 응답을 통해 클라이언트 측이 어떤 정보도 얻지 못하게 하고 싶지 않다면. |
| 404 | 요청이 실패했으며, 원하는 리소스가 서버에서 찾지 못되었습니다. 사용자에게 상태가 일시적이거나 영구적이지 않을지에 대한 정보는 없습니다. 서버가 상황을 알고 있다면, 410 상태 코드는 일부 내부 구성 메커니즘으로 인해 영구적으로 사용할 수 없게 되었고 이동할 주소가 없는 오래된 리소스에 대해 알리기 위해 사용되어야 합니다. 404 서버가 요청이 거부되었음을 밝히고 싶지 않거나 적절한 응답이 없을 때 상태 코드가 널리 사용됩니다. |
| 405 | The request method specified in the request line cannot be used to request the corresponding resource. The response must return an Allow header indicating a list of request methods that can be accepted by the current resource. Since PUT and DELETE methods write to resources on the server, most web servers do not support or do not allow the above request method by default, and will return a 405 요청 라인에 지정된 요청 메서드는 해당 자원을 요청하는 데 사용할 수 없습니다. 응답은 현재 자원이 수락할 수 있는 요청 메서드 목록을 나타내는 Allow 헤더를 반환해야 합니다. PUT 및 DELETE 메서드는 서버의 자원에 쓰기 작업을 수행하므로, 대부분의 웹 서버는 기본적으로 이러한 요청 메서드를 지원하지 않거나 허용하지 않으며, 반환합니다. |
| 406 | 이러한 요청에 대한 오류.-요청 자원의 내용 특성이 요청 헤더에 명시된 조건을 만족하지 않으므로, 응답 엔티티를 생성할 수 없습니다. HEAD 요청이 아니라면, 응답은 사용자나 브라우저가 가장 적합한 엔티티 특성과 주소 목록을 선택할 수 있도록 허용하는 엔티티를 반환해야 합니다. 엔티티의 형식은 Content에 정의된 미디어 타입에 따라 결정됩니다. |
| 407 | 타입 헤더. 브라우저는 형식과 자신의 기능에 따라 최선을 선택할 수 있습니다. 그러나 이러한 자동 선택을 위한 어떤 기준도 명시되어 있지 않습니다. 401 와 유사하게-인증을 위한 인증. 클라이언트 측은 프록시를 반환할 수 있지만, 클라이언트 측은 프록시 서버에서 인증해야 합니다. 프록시 서버는 프록시를 반환해야 합니다.-인증을 위한 Authorization 헤더. RFC를 참조하세요 2617. |
| 408 | 요청이 시간 초과되었습니다. 클라이언트 측이 서버가 기다릴 준비가 되었을 때의 시간 내에 요청을 전송하지 못했습니다. 클라이언트 측은 언제든지 변경 없이 요청을 다시 제출할 수 있습니다. |
| 409 | 요청이 요청 자원의 현재 상태와 충돌로 완료되지 않을 수 있습니다. 이 코드는 사용자가 충돌을 해결할 수 있다고 가정되고 새로운 요청을 다시 제출할 것으로 예상될 때만 사용할 수 있습니다. 응답은 사용자가 충돌의 원인을 파악할 수 있도록 충분한 정보를 포함해야 합니다. 충돌은 보통 PUT 요청 처리 중 발생합니다. 예를 들어, 버전-검증된 환경에서, PUT에 연결된 버전 정보가 있으면-특정 자원에 대한 수정 요청을 제출한 것이 이전(제3자) 요청과 충돌한다면-(제3자) 요청을 받았을 때, 서버는 409 사용자에게 요청이 완료되지 못했다고 알리는 오류
이 시점에서, 응답 엔티티는 사용자가 병합된 버전을 다시 제출할 수 있도록 두 충돌 버전 간의 차이 비교를 포함할 가능성이 높습니다. |
| 410 | 요청한 자원이 서버에서 더 이상 사용할 수 없으며, 알려진 전송 주소가 없습니다. 이 상태는 영구적인 것으로 간주되어야 합니다. 가능한 경우, 링크 편집 기능을 가진 클라이언트 측은 사용자의 허가를 받아 이 주소에 대한 모든 참조를 제거해야 합니다. 서버가 이 상태가 영구적인지 알지 못하거나 결정할 수 없다면, 404 상태 코드를 사용해야 합니다. 기타가 명시되지 않는 한, 이 응답은 캐시할 수 있습니다. 캐시의 목적은 410 응답은 주로 웹마스터가 웹사이트를 유지보수하는 데 도움이 되며, 사용자에게 자원이 더 이상 사용할 수 없음을 알리고, 서버 소유자가 이 자원에 대한 모든 원격 연결을 삭제하고자 하는 것을 알립니다.
이 종류의 이벤트는 시간에 따라 일반적입니다-제한된 값-추가된 서비스. 마찬가지로, 410 응답은 클라이언트 측에 개인이 소유한 자원이 현재 서버 사이트에서 더 이상 사용할 수 없음을 알리기 위해 사용됩니다. 물론, 모든 영구적으로 사용할 수 없는 자원을 '으로 표시할지 여부는 서버 소유자의 전적으로 결정됩니다. 410 Gone ', 그리고 이 표시를 얼마나 오래 유지할지. |
| 411 | 서버는 Content를 정의하지 않고 요청을 수락하지 않습니다.-길이 헤더. 유효한 Content를 추가한 후-요청 본문의 길이를 나타내는 길이 헤더, 클라이언트 측이 요청을 다시 제출할 수 있습니다. |
| 412 | 서버는 청구 헤더 필드에 제공된 요구 사항을 확인할 때 하나 이상의 요구 사항을 충족시키지 못했습니다. 이 상태 코드는 클라이언트 측이 자원을 가져오는 때 요청된 메타데이터(청구 헤더 필드 데이터)에 요구 사항을 설정할 수 있게 하여, 청구 메서드가 원하는 것 외의 자원에 적용되지 않도록 방지합니다. |
| 413 | 서버는 현재 청구를 처리하지 않습니다. 이는 청구가 서버가 받아들이거나 처리할 수 있는 엔티티 데이터보다 많은 데이터를 제출한 경우입니다. 이 경우, 서버는 클라이언트 측이 청구를 계속 전송하는 것을 방지하기 위해 연결을 닫을 수 있습니다. 이 상황이 일시적이면, 서버는 Retry-응답 헤더를 통해 클라이언트 측이 다시 시도할 수 있는 시간을 알리기 위해. |
| 414 | 요청된 URI가 서버가 해석할 수 있는 길이보다 길어서, 서버는 청구를 처리하지 않습니다. 이는 드문 일이며, 일반적인 경우에는: POST 메서드를 사용해야 할 양식이 GET 메서드가 되어서 쿼리 스트링(쿼리 문자열)이 너무 길어지는 경우, Redirect URI "블랙홀", 예를 들어 각 Redirect가 새 URI의 일부로 기존 URI를 사용하는 경우, 여러 Redirect 후 URI가 너무 길어지는 경우 등이 있습니다. 클라이언트가 서버에 보안 버그를 사용하여 공격을 시도하고 있습니다.
이 유형의 서버는 고정된-버퍼를 읽거나 요청된 URI를 조작하기 위해 사용할 길이 버퍼를 제공합니다. GET 이후의 매개변수가 특정 값을 초과하면 버퍼 오버플로우가 발생하여 임의의 코드 실행이 발생할 수 있습니다 [1]. 이러한 취약점이 없는 서버는 다음과 같은 응답을 반환해야 합니다. 414 상태 코드. |
| 415 | 현재 청구 메서드와 요청된 자원에 대해, 청구에서 제출된 엔티티가 서버가 지원하는 형식이 아닌 경우, 청구가 거부됩니다. |
| 416 | 청구에 Range 헤더가 포함되어 있으며, Range에서 지정된 데이터 범위가 현재 자원의 사용 가능한 범위와 일치하지 않는 경우, 그리고 If-청구에서 Range 헤더가 정의되지 않았습니다. 서버는 해당 응답을 반환해야 합니다. 416 상태 코드. Range가 바이트 범위를 사용하면, 이 상황은 요청으로 지정된 모든 데이터 범위의 첫 번째 바이트 위치가 현재 자원의 길이를 초과한다는 것을 의미합니다. 서버는 또한 Content를 포함해야 합니다.-Range 엔티티 헤더와 함께 416 상태 코드를 현재 자원의 길이를 나타내기 위해 사용합니다. 이 응답은 multipart를 사용할 수 없습니다/byteranges로 Content-타입. |
| 417 | 요청 헤더에서 지정된 예상 내용을 서버가 충족시킬 수 없습니다, 또는 서버가 다음 노드에서 예상 내용을 충족시킬 수 없음을 명확히 증거하는 프록시 서버입니다. |
| 421 | 현재 클라이언트 측이 위치한 인터넷 프로토콜 주소에서 서버로의 연결 수가 서버가 허용한 최대 연결 수를 초과합니다. 일반적으로 이곳의 인터넷 프로토콜 주소는 서버에서 볼 수 있는 클라이언트 측 주소(예: 사용자의 게이트웨이나 프록시 서버 주소)를 가리킵니다. 이 경우, 연결 수는 하나 이상의 최종 사용자를 포함할 수 있습니다. |
| 422 | 현재 클라이언트 측이 위치한 인터넷 프로토콜 주소에서 서버로의 연결 수가 서버가 허용한 최대 연결 수를 초과합니다. 일반적으로 이곳의 인터넷 프로토콜 주소는 서버에서 볼 수 있는 클라이언트 측 주소(예: 사용자의 게이트웨이나 프록시 서버 주소)를 가리킵니다. 이 경우, 연결 수는 하나 이상의 최종 사용자를 포함할 수 있습니다. |
| 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 | マイ크로소프트에서 확장된 요청은 적절한 조치를 취한 후 다시 시도해야 합니다. |
| 500 | 서버는 요청을 완료할 수 없게 만드는 예상치 못한 상황을 만났습니다. 일반적으로 이 문제는 서버 코드가 실패했을 때 발생합니다. |
| 501 | 서버가 현재 요청에 필요한 기능을 지원하지 않습니다. 서버가 요청된 메서드를 인식할 수 없고, 어떤 자원에 대한 요청도 지원할 수 없을 때. |
| 502 | 게이트웨이나 프록시로 작동하는 서버가 요청을 실행하려고 할 때, 상위 서버에서 무효한 응답을 받습니다. |
| 503 | 서버는 일시적인 서버 유지보수나 과부하로 인해 요청을 처리할 수 없습니다. 이 상태는 일시적이며 얼마 후 복구됩니다. 지연 시간이 예측 가능하다면, 응답에는 Retry을 포함할 수 있습니다.-헤더를 통해 지연 시간을 나타내기 위해 사용합니다. Retry-정보가 제공되지 않았을 때, 클라이언트 측은 그것을 500 응답. 주의: 503 상태 코드가 서버가 과부하 시 사용해야 하는 것을 의미하지 않습니다. 일부 서버는 단순히 클라이언트의 연결을 거부하고 싶을 뿐입니다. |
| 504 | 게이트웨이 또는 프록시로 작동하는 서버가 요청을 실행하려고 하면, 상류 서버(URI로 식별된 HTTP, FTP, LDAP 등)나 보조 서버(DNS 등)에서 시간 내에 응답을 받지 못합니다. 주의: 일부 프록시 서버는 400 또는 500 DNS 쿼리 타임아웃 시 오류 |
| 505 | 서버가 요청에서 사용된 HTTP 버전을 지원하지 않거나 지원을 거부합니다. 이는 서버가 클라이언트 측과 같은 버전을 사용할 수 없거나 사용하지 않을 것을 의미합니다. 응답에는 버전이 지원되지 않는 이유와 서버가 지원하는 프로토콜을 설명하는 엔티티가 포함되어야 합니다. |
| 506 | 투명 내용 협상 프로토콜로 확장됨 (RFC 2295), 이는 서버 내부 구성 오류를 나타냅니다: 요청된 협상 변수 자원은 투명 내용 협상에서 자신을 사용하도록 설정되어 있으며 따라서 협상 과정에서 적절한 중심이 아닙니다. |
| 507 | 서버는 요청을 완료하기 위해 필요한 내용을 저장할 수 없습니다. 이 상태는 일시적인 것으로 간주됩니다. WebDAV (RFC 4918) |
| 509 | 서버가 밴드위드 제한에 도달했습니다. 이는 공식 상태 코드가 아니지만 여전히 널리 사용됩니다. |
| 510 | 자원을 획득하기 위한 정책이 충족되지 않았습니다. (RFC 2774) |
