각 Status-Code 가 어떤 method를 따를 수 있는가에 대한 설명과 응답에서 필요로 하는 헤더 정보를 포함하여 아래에 설명되어 있다.

1. 정보를 알려 주는 1xx

이 상태 코드 클래스는 잠정적인 응답을 표시하며 Status-Line과 선택적인 헤더로 구성되어 있다. 이 클래스는 빈 라인으로 종료된다. HTTP/1.0은 어떠한 1xx 상태 코드로 정의하지 않기 때문에 실험적인 상황 이외에 서버는 1xx 응답을 HTTP/1.0 클라이언트에 발송해서는 안 된다.

1. 100 계속

클라이언트는 요구를 계속 진행할 수 있다. 이 잠정적인 응답은 클라이언트에게 요청의 일부분이 수신되었으며 서버가 아직 거부하지 않았음을 알리는 데 사용한다. 클라이언트는 요청의 나머지 부분을 발송하여야 하며 요청이 완료 되었으면 이 응답을 무시해야 한다. 서버는 요청이 완료된 다음 마지막 응답을 발송한다.

2. 101 규약 전환

서버가 받아들였으며 Upgrade 메시지 헤더 필드(14.41 절)를 통하여 접속에 사용되고 있는 애플리케이션 규약 변경에 관한 클라이언트의 요구에 따른다. 서버는 101 응답을 종료하는 빈 라인 바로 다음 응답 메시지의 Upgrade 헤더 필드가 정의한 규약으로 전환할 것이다.
규약은 전환하는 것이 유리한 경우에만 전환된다. 예를 들어 새로운 버전의 HTTP로 전환하는 것이 이전 버전을 사용하는 것보다 유리하며 해당 기능을 사용하는 자원을 전송할 때 실시간, 동시 규약으로 전환하는 것이 유리하다.

2. 성공을 알리는 2xx

이 상태 코드 클래스는 클라이언트의 요구가 성공적으로 수신, 해석 및 접수되었음을 표시한다.

1. 200 OK

요청을 성공적으로 전달하였다. 응답과 함께 반환되는 정보는 요청에 사용된 method에 달려 있다.

요청	반환 정보
GET	요청한 자원에 상응하는 개체는 응답에 포함되어 발송된다.
HEAD	요청한 자원에 상응하는 Entity-Header 필드는 Message-Body 없이 응답에 포함되어 발송된다.
POST	처리 결과를 설명 또는 포함하는 개체.
TRACE	서버가 받은 요청 메시지를 포함하고 있는 개체.

2. 201 Created 생성됨

요구가 충족되었으며 새로운 자원이 생성되었다. 새로 생성된 자원은 응답 엔터티에 반환된 URI를 통하여 참조할 수 있으며 자원의 가장 상세한 URL은 Location 헤더 필드로 알 수 있다. 원서버는 201 상태 코드를 리턴하기 전에 반드시 자원을 생성해야 한다. 처리가 즉각적으로 수행될 수 없을 때에 서버는 202(Accepted) 응답으로 대신 응해야 한다.

3. 202 Accepted 접수됨

처리를 위해 요청을 접수하였으나 처리는 완료되지 않았다. 요구는 엔터티의 처리 과정에서 허용되지 않을 수도 있기 때문에 궁극적으로 처리되었을 수도 있고, 처리되지 않았을 수도 있는 애매한 상태 코드이다. 202 응답은 의도적으로 작업을 수행하지 않는다. 이 응답의 목적은 사용자 서버가 처리 완료 응답을 받을 때까지 요청 서버에 지속적으로 연결하지 않고서도 다른 처리에 대한 요구사항을(하루에 한 번만 실행되는 배치 지향적인 프로세스일 수도 있다.) 접수할 수 있도록 하는 데 있다. 이 응답을 리턴하는 엔터티는 상태 점검자(monitor)에 대한 지시자 또는 사용자가 언제 요구가 완료될 수 있는지에 대한 예상 및 요구의 현재 상태에 대한 표시를 포함해야 한다.

4. 203 Non-Authoritative Information 인증되지 않은 정보

Entity-Header에 반환된 메타데이터는 복사본에서 수집한 것이다. 제시된 세트는 원래 버전의 하위 세트 또는 상위 세트일 수 있다. 이 응답 코드를 사용하는 것은 의무사항이 아니며 응답이 203이 아니면 200 (OK)일 때만 적합하다.

5. 204 No Content 내용 없음

서버가 요청을 완전히 처리 했으나 리턴할 새로운 정보가 없다. 클라이언트가 사용자 에이전트이면 요청을 발송하도록 한 도큐먼트 내용을 변경해서는 안 된다. 응답은 Entity-Header 형태의 새 메타데이터를 포함한다. 204 응답은 Message-Body를 포함해서는 안되며 항상 헤더 필드 다음의 첫 빈 라인으로 종료된다.

6. 205 Reset Content 내용을 지움

서버가 요청을 완전히 처리하였으며 사용자 에이전트는 요구를 발송하도록 한 도큐먼트의 내용을 지워야한다. 이 응답은 주로 사용자 입력을 통하여 처리를 위한 입력이 발생하도록 하기 위해 사용한다. 이 응답 뒤에 입력을 수행한 폼을 지워 사용자가 다른 입력 요구를 쉽게 시작할 수 있게 한다. 이 응답은 엔터티를 포함해서는 안 된다.

7. 206 Partial Content 부분적으로 완료

서버가 자원에 대한 부분적 GET 요구를 완료하였다. 이 요구는 반드시 원하는 영역을 표시하는 Range 헤더 필드(14.36 절)를 포함해야 한다. 응답은 이 응답에 포함된 영역을 표시하는 Content-Range 헤더 필드(14.17 절)나 각 파트의 Content-Range 필드를 포함하는 multipart/byteranges Content-Type을 포함해야 한다. multipart/byteranges를 사용하지 않았으면 응답의 Content-Length 헤더 필드는 Message-Body로 전송된 OCTET의 실제 숫자와 정확하게 일치해야 한다. Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206(Partial Content) 응답을 캐시해서는 안된다.

3. 방향을 재설정하는 3xx

이 상태 코드 클래스는 사용자 에이전트가 요구를 완전히 처리하기 위해서는 추가적인 처리가 필요하다는 것을 표시한다. 요구되는 처리는 두 번째 요구에 사용된 method가 GET 또는 HEAD일 경우에만 사용자와의 상호작용 없이도 수행될 수 있다. 사용자 에이전트는 이러한 방향 재설정이 무한 루프를 표시하는 것이기 때문에 다섯 번 이상 자동적으로 요구 방향 재설정을 해서는 안 된다.

1. 300 Multiple Choices 복수 선택

요구된 자원이 각자 자신 특유의 위치를 가지고 있는 표현 세트 중의 하나와 대응되며 사용자가 선호하는 표현 방식을 선택하고 요구를 해당 위치로 재설정할 수 있도록 에이전트가 주도하는(agent-driven) 협상 정보가 제공된다.
HEAD 요구가 아닌 이상 응답은 사용자가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함한다. 개체 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시된다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있다. 그러나 이 규격은 이러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않는다. 서버가 선호하는 표시 방법을 가지고 있으면 Location 필드에 해당 표시 방법에 대한 상세한 URL을 포함해야 한다. 사용자 에이전트는 Location 필드 값을 이용하여 자동으로 방향을 재설정할 수 있다. 이 응답은 별도의 표시가 없는 한 캐시할 수 있다.

2. 301 Moved Permanently 영구 이동

요구된 자원에 새로운 영구 URI가 할당되었으며 향후 이 자원에 대한 참조는 리턴 된 URI 중 하나를 이용하여 이루어질 수 있다. 링크를 편집할 수 있는 능력이 있는 클라이언트는 가능하다면 Request-URI에 대한 참조를 서버가 리턴한 새로운 참고처로 자동적으로 재링크시켜야 한다. 다르게 표시되어 있지 않으면 이 응답은 캐시할 수 있다. 새로운 URI가 위치하면 해당 URL은 응답의 Location 필드가 부여해야 한다. 요구 method가 HEAD가 아니면 응답의 엔터티는 새로운 URI로의 하이퍼링크가 표시된 짧은 하이퍼텍스트 주석을 포함하고 있어야 한다. GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는 사용자가 확인하지 않는 한 요구를 발행한 조건을 \ 변경할 수도 있기 때문에 자동적으로 요구의 방향을 재설정해서는 안 된다.

주의 : 301 상태 코드를 수신한 후 자동적으로 POST 요구의 방향을 재설정할 때 기존의 몇몇 HTTP/1.0 사용자 에이전트는 실수로 POST 요구를 GET 요구로 변경한다.

3. 302 Moved Temporarily 임시 이동

요구된 자원이 별도의 URI에 임시로 보관되어 있다. 방향 재설정은 종종 변경될 수 있기 때문에 클라이언트는 향후 요구를 위해서 계속해서 Request-URI를 사용해야 한다. 이 응답은 Cache- Control 또는 Expires 헤더 필드가 표시할 경우에만 캐시할 수 있다.

새로운 URI가 위치이면 해당 URL은 응답의Location 필드가 부여해야 한다. 요구 method가 HEAD가 아니면 응답의 엔터티는 새로운 URI로의 하이퍼링크가 표시된 짧은 하이퍼텍스트 주석을 포함하고 있어야 한다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는 사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구의 방향을 재설정 해서는 안 된다.

주의 : 301 상태 코드를 수신한 후 자동적으로 POST 요구의 방향을 재설정할 때 기존의 몇몇 HTTP/ 1.0 사용자 에이전트는 실수로 POST 요구를 GET 요구로 변경한다.

4. 303 See Other 다른 것을 참조

요구된 자원이 별도의 URI에 임시로 보관되어 있으며 해당 자원에서 GET method를 사용하여 조회 해야 한다. 이 method는 주로 POST가 활성화한 스크립트의 산출물을 사용자 에이전트가 선택된 자원으로 방향을 재설정할 수 있도록 하기 위해 사용된다. 새로운 URI는 처음 요구된 자원에 대한 대체 참고처가 아니다. 303 응답은 캐시할 수 없으나 두 번째(재설정된) 요구에 대한 응답은 캐시할 수 있다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는 사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구의 방향을 재설정 해서는 안 된다.

5. 304 Not Modified 변경되지 않았음

클라이언트가 조건적 GET 요구를 실행했고 접근할 수 있으나 문서가 변경되지 않았으면 서버는 이 상태 코드로 응답해야 한다. 이 응답은 Message-Body를 포함해서는 안 된다.

응답은 다음의 헤더 필드를 포함하고 있어야 한다.

• 날짜

• ETag 및/또는 Content-Location, 동일한 요구에 대한 200 응답 속에 헤더가 발송되었을 경우

• Expires, Cache-Control, 및/또는 Vary, 동일한 변이에 대한 이전 응답 속에 발송된 field- value가 상이할 경우

조건적 GET이 강한 캐시 검증자(13.3.3 절 참조)를 사용했다면 응답은 다른 Entity-Header를 포함해서는 안 된다. 그렇지 않으면(조건적 GET이 약한 캐시 검증자를 사용할 때) 응답은 Entity-Header을 포함해 서는 안 된다. 이렇게 하여 캐시 된 Entity-Body과 갱신된 헤더 사이의 불일치를 방지할 수 있다.

304 응답이 현재 캐시 되지 않은 엔터티를 표시할 때 캐시는 이 응답을 무시하고 조건 없이 요구를 반복해야 한다.

캐시가 수신한 304 응답을 캐시 엔트리의 갱신에 사용한다면 캐시는 응답이 가지고 있는 새로운 필드 값을 반영하기 위해 엔트리를 반드시 갱신해야 한다.

304 응답은 Message-Body를 포함해서는 안되므로 항상 헤더 필드 다음의 첫 공백 라인으로 종료되어야 한다.

6. 305 Use Proxy 프록시를 사용해라

요구된 자원을 Location 필드에 명시된 프락시를 통하여 접근해야만 한다. Location 필드가 프록시의 URL을 제공한다. 수신측은 프록시를 통한 요구를 반복할 것으로 기대된다.

4. Client Error 4xx (클라이언트 에러 4xx)

상태 코드의 4xx 클래스는 클라이언트가 에러를 발생한 것처럼 보일 경우에 사용된다. HEAD 요구에 응답하는 경우를 제외하고는 서버는 임시적이건 영구적이건 에러 상황에 대한 설명을 포함한 엔터티를 포함해야 한다. 이러한 상태 코드는 모든 요구 method에 적용할 수 있다. 사용자 에이전트는 사용자에게 포함된 엔터티를 표시해야 한다.

주의 : 클라이언트가 데이터를 발송한다면 TCP를 사용하는 서버 구현 방식은 서버가 입력 접속을 종료 하기 전에 응답을 포함하고 있는 패킷 접수를 확인할 수 있도록 주의해야 한다. 클라이언트가 접속이 종료된 후에도 계속해서 데이터를 전송한다면 서버의 TCP 스택은 리셋 패킷을 클라이언트에게 발송할 것이다.

이 리셋 패킷은 HTTP 애플리케이션이 읽거나 해석하기 전에 클라이언트가 확인한 입력 버퍼를 지운다.

1. 400 Bad Request 잘못된 요청

잘못된 형식 때문에 서버가 요구를 이해할 수 없다. 클라이언트는 변경 없이 요구를 반복해서는 안 된다.

2. 401 Unauthorized 인증되지 않음

응답이 사용자 인증을 요구한다. 이 응답은 요구된 자원에 적용할 수 있는 설명 요구(challenge)를 포함하고 있는 WWW-Authenticate 헤더 필드(14.46 절)를 포함하고 있어야 한다. 클라이언트는 적절한 Authorization 헤더 필드(14.8 절)를 가지고 요구를 반복할 수 있다. 요구가 벌써 Authorization 증명서를 포함하고 있다면 401 응답은 해당 증명서에 대한 인증이 거절되었음을 표시한다. 401 응답이 이전 응답과 동일한 설명 요구를 포함하고 있고 사용자 에이전트가 한 번 이상 인증 획득을 시도했다면 해당 엔터티가 관련된 진단 정보를 포함하고 있기 때문에 사용자에게 응답에 표시된 엔터티를 표시해주야 한다. HTTP 접속 인증은 11 장에 설명되어 있다.

이 코드는 향후 사용을 위해 예약되었다.

3. 403 Forbidden 금지됨

서버가 요구를 이해했으나 완료하는 것을 거절하고 있다. 인증은 적용되지 않으며 요구를 반복될 수 없다. 요구 method가 HEAD가 아니고 서버가 왜 요구가 완료되었는지 알리고 싶다면 엔터티 안에 거절한 이유를 기록해야 한다. 이 상태 코드는 서버가 요구가 거부 사유를 밝히기 원하지 않을 때나 다른 응답을 적용할 수 없을 때 일반적으로 사용된다.

4. 404 Not Found 찾을 수 없음

서버가 Request-URI와 일치하는 것을 아무것도 발견하지 못했다. 이러한 상태가 잠정적인지 영구적 인지 관한 아무런 표시도 주어지지 안는다.

서버가 이 정보를 클라이언트에게 알리고 싶지 않을 경우 상태 코드 403(Forbidden)을 대신 사용할 수 있다. 내부적으로 환경을 설정할 수 있는 메커니즘을 통하여 이전의 자원을 영구적으로 사용할 수 없으며 전송 주소가 없다는 것을 알 수 있으면 410(Gone) 상태 코드를 사용한다.

5. 405 Method Not Allowed Method를 사용할 수 없음

Request-Line에 명시된 method를 Request-URI로 확인할 수 있는 자원에서 사용할 수 없다. 응답은 요구된 자원에 사용할 수 있는 method의 목록을 포함한 Allow 헤더를 포함해야 한다.

6. 406 Not Acceptable 받아들일 수 없음

요구가 확인한 자원이 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는 내용 특징을 가지고 있는 응답 엔터티만을 생성할 수 있다.

HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함한다. 엔터티 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시된다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있다. 그러나 이 규격은 그러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않는다.

주의 : HTTP/1.1 서버는 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는 응답을 리턴할 수 있게 한다. 어떤 경우엔 이것이 406 응답을 발송하는 것보다 좋을 수도 있다. 사용자 에이전트는 도착하는 응답의 헤더를 검사하여 그것의 접수 여부를 결정하도록 추천한다. 응답을 접수할 수 없을 때 사용자 에이전트는 잠정적으로 더 이상의 데이터를 수신하지 말아야 하며 추가 행동을 취할 것인지 사용자에게 질의한다.

7. 407 Proxy Authentication Required 프록시 인증이 요구됨

이 코드는 401(Unauthorized)과 유사하지만 클라이언트는 먼저 프록시에서 자기 자신을 인증해야 한다는 것을 표시한다. 프록시는 요구된 자원의 프록시에 적용할 수 있는 설명 요구를 포함하는 Proxy-Authenticate 헤더 필드(14.33 절)를 리턴해야 한다. 클라이언트는 적절한 Proxy- Authorization 헤더 필드(14.34 절)와 함께 요구를 반복해야 한다. HTTP 접속 인증 획득에 대해서는 11 장에 설명되어 있다.

8. 408 Request Timeout 요구 시간 초과

클라이언트가 서버가 기다리도록 준비한 시간 내에 요구를 만들어 낼 수 없다. 클라이언트는 나중에 변경 없이 요구를 반복할 수 있다.

9. 409 Conflict 충돌

자원의 현재 상태와의 충돌 때문에 요구를 완료할 수 없다. 이 코드는 사용자가 충돌을 해결하고 요구를 재전송할 수 있을 것으로 기대할 수 있는 상황에서만 사용할 수 있다. 응답 본문은 사용자가 충돌의 원인을 인지할 수 있도록 충분한 정보를 포함해야 한다. 이상적으로는 응답 엔터티가 사용자 또는 사용자 에이전트가 문제를 해결할 수 있을 정도의 충분한 정보를 포함할 수 있을 것이다. 그러나 가능하지 않을 수도 있으며 필수 사항은 아니다.

충동은 PUT 요구에 대한 응답으로 발생할 가능성이 높다. 버전 관리를 사용하고 있고 PUT 요구를 하는 엔터티가 이전 요구(제 3 자)가 작성한 요구와 충돌되는 자원에 대한 변경 사항을 포함하고 있다면 서버는 409 응답을 사용하여 요구를 완료할 수 없음을 표시해야 한다. 이 경우 응답 엔터티는 응답 Content-Type이 규정한 형식으로 두 버전 사이의 차이점 목록을 포함해야 한다.

10. 410 Gone 내용이 사라짐

요구된 자원이 서버에 더 이상 존재하지 않으며 전송 주소를 알 수 없다. 이 조건은 영구적인 것으로 간주해야 한다. 링크를 편집할 기능이 있는 클라이언트는 사용자 인증 후의 Request-URI에 대한 참고는 삭제해야 한다. 서버가 그 조건이 영구적인지 여부를 알 수 없거나 결정할 시설이 없으면 상태 코드 401(Unauthorized)을 대신 사용해야 한다. 다르게 표시되지 않는 한 이 응답은 캐시할 수 있다.

410 응답은 주로 수신측에게 자원을 의도적으로 사용할 수 없게 하였고 서버의 소유주가 해당 자원에 대한 원격 링크를 제거하고자 한다는 것을 알림으로써 웹 유지 작업을 지원하기 위해 사용된다. 이러한 일은 제한된 시간, 선전용 서비스 및 서버의 사이트에서 더 이상 일하지 않는 개인에게 소속된 자원에서 공통적으로 발생할 수 있다. 영구적으로 사용할 수 없는 모든 자원을 “사라진” 것으로 표시하 거나 특정 시간 동안 표시를 유지할 필요는 없다. - 이것은 서버 소유자의 판단에 달려 있다.

11. Length Required 길이가 필요함

서버가 규정된 Content-Length 없는 요구 접수를 거부하였다. 요구 메시지 내의 Message-Body의 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가한다면 클라이언트는 요구를 반복할 수 있다.

12. 412 Precondition Failed 사전 조건 충족 실패

하나 또는 그 이상의 Request-Header 필드에 기입된 사전 조건이 서버에서 테스트 했을 때 거짓 으로 평가되었다. 이 응답 코드는 클라이언트가 현재 자원의 메타 정보에 사전 조건을 부여할 수 있게 하여 의도하지 않는 자원에 요구 method를 적용하는 것을 방지한다.

13. 413 Request Entity Too Large 요청 개체가 너무 큼

요구 엔터티가 서버가 처리할 수 있거나 처리하려는 것보다 크기 때문에 서버가 요구 처리를 거부 하였다. 서버는 클라이언트가 계속적으로 요구하는 것을 방지하기 위하여 연결을 종료한다.

조건이 잠정적이면 서버는 Retry-After 헤더 필드를 포함하여 조건이 잠정적이며 얼마 후에 클라이 언트가 재시도할 것인지를 표시한다.

14. 414 Request-URI Too Long 요청 URI가 너무 큼

Request-URI가 서버가 해석할 수 있는 것보다 크기 때문에 서버가 요구 처리를 거부하였다. 이처럼 드문 조건은 클라이언트가 부적절하게 질의 정보가 긴 POST 요구를 GET 요구로 변환했을 때, 클라이언트가 방향 재설정의 URL “블랙 홀”로 빠졌을 때(방향이 재설정된 URL 접두사가 자신의 접미사를 지칭할 때), Request-URI를 읽거나 조작하는 고정-길이 버퍼를 사용하는 몇몇 서버에 존재하는 보안의 허점을 이용하려는 클라이언트로부터 서버가 공격을 받을 때만 발생하는 것 같다.

15. 415 Unsupported Media Type 지원하지 않는 미디어 타입

요구의 엔터티가 요구 받은 method의 자원이 지원하지 않는 포맷으로 구성되어 있기 때문에 요구 처리를 거부하였다.

5. Server Error 5xx(서버 에러 5xx)

숫자 “5”로 시작하는 응답 상태 코드는 서버가 에러를 발생시켰으며 요구를 처리할 능력이 없음을 인지한 경우를 표시한다. HEAD 요구에 응답하는 때를 제외하고는 서버는 에러 상황에 대한 설명 및 에러가 잠정적인지 영구적인지에 관한 상황 설명을 포함하는 엔터티를 포함해야 한다. 사용자 에이전트는 포함된 모든 엔터티를 사용자에게 표시하여야 한다. 이러한 응답 코드는 모든 요구 method에 적용할 수 있다.

1. 500 Internal Server Error 서버 내부 에러

서버가 요구를 처리하지 못하도록 하는 예상치 못한 상황에 접했다.

2. 501 Not Implemented 기능을 지원하지 않는다. 구현되지 않음

서버가 요구를 완료하는 데 필요한 기능을 지원하지 않는다. 이것은 서버가 요구 method를 인지할 수 없고 어떠한 자원을 사용해도 지원할 수 없을 때 적절한 응답이다.

3. 502 Bad Gateway 게이트웨이 에러

게이트웨이나 프록시 역할을 수행하는 서버가 요구를 완료하려는 시도에서 접근한 업스트림 (upstream) 서버로부터 유효하지 않은 응답을 수신했을 경우이다.

4. 503 Service Unavailable 서비스를 사용할 수 없음

서버가 현재 잠정적인 오버로딩(overloading)이나 서버의 유지 작업 때문에 요구를 처리할 수 없다. 이것의 의미는 이것이 잠정적인 상황이며 얼마 후에는 완화될 수 있다는 것이다. 알 수 있다면 지연 시간 길이를 Retry-After 헤더에 표시할 수 있다. 아무런 Retry-After 정보가 없으면 클라이 언트는 500 응답을 처리하는 것처럼 응답을 처리해야 한다.

주의 : 503 상태 코드가 있다는 것이 서버가 오버로드 되었을 때 이것을 반드시 사용해야 된다는 것을 의미하지 않는다. 어떤 서버는 단순히 접속을 거부하고자 한다.

5. 504 Gateway Timeout 게이트웨이 시간 초과

게이트웨이나 프록시 역할을 수행하는 서버가 시간 내에 요구를 완료하려는 시도에서 접근한 업스트림(upstream) 서버로부터 응답을 수신하지 못했을 경우이다.

6. 505 HTTP Version Not Supported 지원하지 않는 HTTP 버전

서버가 요구 메시지에서 사용된 HTTP 규약 버전을 지원하지 않거나 지원하기를 거부했다. 서버는 이 에러 메시지 이외에는 3.1 절에서 설명한 대로 클라이언트가 사용하는 동일한 주요 버전을 사용하여 요구를 완료할 의사나 능력이 없음을 표시한다. 응답은 왜 해당 버전이 지원되지 않으며 서버가 어떤 규약을 지원하는가를 설명하는 엔터티를 포함해야 한다.

출처 : http://iorora.web-bi.net/tech/ETCnetwork/rfc/rfc2068-kr.html

comments powered by Disqus