RFC 7231

https://datatracker.ietf.org/doc/html/rfc7231 RFC 7231 - HTTP/1.1 : Semantics and Content 번역

6. Response Status Codes

6. 응답 상태 코드

• status-code 요소는 요청을 이해하고 충족시키려는 시도의 결과를 제공하는 세자리 정수 코드
• HTTP 상태 코드는 확장가능
  • HTTP 클라이언트는 등록된 모든 상태 코드의 의미를 이해할 필요는 없지만, 그러한 이해는 분명히 바람직하다.
  • (MUST) 그러나 클라이언트는 첫번째 숫자로 표시된 상태 코드의 클래스를 이해하고 인식되지 않는 상태 코드를 해당 클래스의 x00상태 코드에 해당하는 것으로 취급해야하며,
  • (MUST NOT) 단, 수신자는 인식되지 않는 상태 코드로 응답을 캐시하면 안된다는 점을 제외한다.
  • 상태코드의 첫번째 자릿수: 응답 클래스를 정의
    • 1xx(Informational): 요청이 수신되어 프로세스가 계속 진행됨
    • 2xx(Successful): 요청이 성공적으로 수신, 이해 및 수락됨
    • 3xx (Redirection): 요청을 완료하려면 추가 조치를 취해야 함
    • 4xx(ClientError): 요청에 잘못된 구문이 포함되어 있거나 충족할 수 없음
    • 5xx(ServerError): 서버가 유효한 요청을 수행하지 못함

6.1 Overview of Status Codes

• (생략)
• 기본적으로 캐시 가능으로 정의된 상태 코드(e.g., 이 명세의 200, 203, 206, 300, 301, 404,405,410,414및501)의 응답은 메서드 정의나 명시적 캐시 제어[RFC7234]에 달리 명시되지 않는 한 휴리스틱한 만료를 가진 캐시에 의해 재사용할 수 있으며, 다른 모든 상태 코드는 기본적으로 캐시가능하지 않다.
• (생략)
• 상태코드의 전체 목록은 IANA에 의해 유지된다. 자세한 내용은 Section 8.2를 참조한다.

6.4 Redirection 3xx

• 상태 코드의 3xx(Redirection) 등급은 요청을 이행하기 위해 사용자 에이전트의 추가 조치가 필요하다는 것을 나타낸다. Location 헤더 필드(Section7.1.2)가 제공되는 경우, 사용자 에이전트는 특정 상태 코드를 이해하지 못하더라도 Location 필드 값이 참조하는 URI로 요청을 자동으로 리다이렉트할 수 있다. 사용자가 안전하지 않은 요청을 리다이렉트하기를 원하지 않을 수 있으므로, Section 4.2.1에서 정의한대로 안전하지 않은 메소드를 주의하여 자동 리다이렉트를 수행해야 한다.
• 여기에 리다이렉트의 몇 가지 유형이 있다:
  1. 상태코드 301(Moved Permanently), 302(Found), 307(TemporaryRedirect)과 같이 Location 필드에서 제공하는대로 다른 URI에서 리소스를 사용할 수 있음을 나타내는 리다 이렉트.
  2. 300(Multiple Choices) 상태 코드에서와 같이 각각 원래의 요청 대상을 나타낼 수 있는 매칭 리소스의 선택을 제공하는 리다이렉트.
  3. 303(See Other) 상태 코드에서와 같이 요청에 대한 간접적인 응답을 나타낼 수 있는 위치 필드로 식별된 다른 리소스로의 리다이렉트.
  4. 304(Not Modified) 상태 코드에서와 같이 이전에 캐시된 결과로 리다이렉트.
  • 참고
    • HTTP/1.0에서는 첫 번째 리디렉션 유형([RFC1945], Section 9.3)에 대한 상태 코드 301(Moved Permanently) 및 302(Found)가 정의되었다.
    • 초기 사용자 에이전트는 리다이렉트 대상에 적용된 메서드가 원래 요청과 같을것인지 아니면 GET로 다시 작성될 것인지에 대해 분할했다. HTTP는 원래 301과 302에 대한 이전의 의미론(CERN에서 원래 구현과 일치하도록 하기 위해)을 정의하고, 303(See Other)을 후자의 의미론과 일치하도록 정의했지만, 지배적인 관행은 301과 302에 대해서도 점차적으로 후자의 의미론에 융합되었다.
    • HTTP/1.1의 첫번째 개정은 307(Temporary Redirect)을 추가하여 다양한 관행에 영향을 받지 않고 이전의 의미론을 표시하였다. 10년이 지난 후에도 대부분의 사용자 에이전트는 여전히301과 302에 대해 메서드 재작성을 한다. 따라서 이 규격은 원래 요청이 POST 일 때 그러한 행동을 준수하도록 한다.
• (생략)

6.4.2. 301 Moved Permanently

• 301(Moved Permanently) 상태 코드는 대상 리소스에 새 영구 URI가 할당되었으며 이 리소스에 대한 향후 참조는 동봉된 URI 중 하나를 사용해야 함을 나타낸다. 링크 편집 기능을 가진 클라이언트는 가능한 경우, 서버가 보낸 하나 이상의 새로운 참조에 유효한 요청 URI에 대한 참조로 자동으로 다시 연결해야 한다.
• (SHOULD) 서버는 새 영구 URI에 대한 기본 URI 참조가 포함된 응답에 Location 헤더 필드를 생성해야 한다.
  • (MAY) 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 사용할 수 있다.
  • 서버의 응답 페이로드에는 일반적으로 새 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼 텍스 트 노트가 포함되어 있다.
• 참고: 역사적 이유로, (MAY) 사용자 에이전트는 후속 요청에 대한 요청 메서드를 POST에서 GET로 변경할 수 있다.
  • 이 동작이 원치 않으면 307(Temporary Redirect) 상태 코드를 대신 사용할 수 있다.
• 301 응답은 기본적으로 캐시할 수 있다.
  • 즉, 메서드 정의나 명시적 캐시 제어에 의해 달리 명시되지 않는 한 ([RFC7234]의 Section 4.2.2 참조).

6.4.7. 307 Temporary Redirect

• 307(Temporary Redirect) 상태 코드는 대상 리소스가 일시적으로 다른 URI에 상주하고 있다는 것을 나타내며, (MUST NOT) 사용자 에이전트는 해당 URI로 자동 리디렉션을 수행할 경우 요청 메서드를 변경하면 안된다.
• 리디렉션은 시간이 지남에 따라 변경될 수 있으므로 클라이언트는 향후에 원래의 유효한 요청 URI를 계속 사용해야 한다.
• (SHOULD) 서버는 다른 URI에 대한 URI 참조가 포함된 응답에 Location 헤더 필드를 생성해야 한다.
  • (MAY) 사용자 에이전트는 자동 리디렉션에 Location 필드 값을 사용할 수 있다.
  • 서버의 응답 페이로드에는 일반적으로 다른 URI에 대한 하이퍼링크가 포함된 짧은 하이퍼 텍스 트 노트가 포함되어 있다.
• 참고: 이 상태 코드는 요청 메서드를 POST에서 GET로 변경할 수 없다는 점을 제외하고 302(Found)와 유사하다. 이 명세는 301 (Moved Permanent)에 해당하는 상대방은 정의하지 않지만 이 목적을 위한 상태코드 308(Permanent Redirect)을 정의한다. [RFC7238])