본문 바로가기

BE

HTTP 상태코드 3xx

728x90

상태코드 3xx (Redirection)

  • 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 함을 의미

301 Moved Permanently 영구 이동 지정한 리소스가 새로운 URI로 이동하였다.이동할 곳의 새로운 URI는 응답 헤더 Location에 기록합니다.

302 Found 다른 위치 찾음 요청한 리소스를 다른 URI에서 찾았다.요청한 URI가 없으므로 클라이언트 메소드를 그대로 유지한 채 응답 헤더 Location에 표시된 다른 URI로 요청을 재송신할 필요가 있습니다. 302의 의미를 정확하게 개선해서 307을 정의하였으므로 이 응답 코드의 사용은 권장하지 않습니다.
304 Not Modified 수정되지 않음 마지막 요청 이후 요청한 페이지는 수정되지 않았다.If-Modified-Since와 같은 조건부 GET 요청일 때 지정한 리소스가 갱신되지 않았음을 알려 줍니다. 이 응답 코드에는 바디가 없습니다.

(이외에도 여러 상태코드가 존재하지만 이번 주제에서 주요하게 다룰 것만 소개하겠다.)

리다이렉션(Redirection)이란 ?

  • URL(Uniform Resource Locator)를 재작성하고 클라이언트의 브라우저에게 다른 URI(Unified Resource Identifier)에 다시 요청하도록 지시하는 HTTP 프로토콜 메시지
  • 일반적으로 웹 사이트의 URL을 영구적으로 또는 일시적으로 변경해야 하는 경우에 사용
  • 예를 들어, 리다이렉션은 사용자가 이전 URL을 입력하거나 이미 사라진 예전 페이지를 클릭하더라도 새 URL로 자동으로 이동할 수 있도록 돕는다.

즉, 클라이언트로부터 요청을 받은 후, 클라이언트에게 특정 URL로 이동하라고 요청하는 것을 말한다.

리다이렉션 동작 원리 및 예시

리다이렉션 설명

  1. 사용자: /event 페이지 보여줘
  2. 서버: 그 주소는 301 /new-event로 바뀌었습니다 (301 Moved Permanently)
  3. 자동 리다이렉트 (이동할 곳의 새로운 URI(/new-event)는 응답 헤더 Location에 기록)
  4. 요청 : /new-event 보여줘
  5. 서버: 넵 (200 OK)

301 vs 302 비교 및 예시

상태코드 301 예제

위와 달리 이 과정에서는 똑같은 301 상태코드임에도 불구하고 POST 요청이 GET으로 변하면서 본문이 제거된 것을 확인할 수 있다.

클라이언트는 이 상태 코드를 받으면 새로운 URL로 자동으로 GET요청을 보내도록 프로토콜에 따라 동작한다. 리다이렉션은 새로운 URL로 GET요청을 보내도록 지시하며 GET요청은 본문(body)을 포함하지 않기 때문에 POST요청의 본문은 제거된다.

이에 반해, 302는 리소스의 URI가 일시적으로 변경된 경우를 뜻하기 때문에 새로운 URL로 이동해야 함을 알려준다. 302는 리소스의 URI가 변경되었지만 이 변경은 일시적으로, 검색 엔진 등이 해당 URL을 재방문할 때 원래 URL(바뀌기 이전)로 돌아갈 수도 있다.

cf. PRG (POST-Redirect-GET 패턴)

PRG란 웹 개발 시 권장되는 디자인 패턴 중 하나로 POST 방식으로 온 요청에 대해 GET 방식의 웹페이지로 리다이렉트 시키는 것을 뜻한다.

PRG 사용 이유

  1. 중복 제출 방지 (POST로 상품 주문 후 브라우저를 새로고침 하면 다시 POST요청이 되고 중복 주문이 될 수 있는데 PRG를 사용하면 GET으로 리다이렉트 됨)
  2. 사용자 경험 개선 (POST 요청 후 브라우저가 리다이렉션을 통해 GET을 보내면 사용자는 화면을 새로고침하거나 다시 제출할 필요가 없어짐)
  3. 안전한 데이터 처리 (비밀번호 변경 후 새로고침을 누르면 양식이 다시 제출되지 않아 비밀번호가 2번 변경되는 것을 방지)
  4. 검색 엔진 최적화 (검색 엔진은 이 GET요청에 따라 새로운 페이지를 인덱싱 하므로 SEO에 도움이 됨)

302 vs 304 비교 및 예시

상태코드 304 예제

304 코드는 수정되지 않음을 나타내고 클라이언트가 이전에 받았던 리소스가 서버에서 변경되지 않았음을 나타낸다. 클라이언트는 이 응답을 받으면 캐시 된 리소스를 사용하고, 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.(캐시로 리다이렉트 수행)

즉, 302는 새로운 주소로의 리다이렉트를 수행하지만 304는 실제 리소스 데이터가 포함되는 것이 아닌 이전에 캐시 한 리소스를 그대로 사용하는 캐시로의 리다이렉트를 수행한다.

만약 304 코드가 문제가 되는 경우 브라우저에 저장된 캐시를 비운 후 확인해 보면 200을 받아올 수 있다.

리다이렉션 결론 및 활용법

  • 302 → GET으로 변할 수도 있다.
  • 처음 302의 의도는 HTTP 메서드를 유지하는 것인데 웹 브라우저들이 대부분 GET으로 바꾸어버리고 이 과정에서 데이터 유실이 발생한다. → 모호한 302를 사용하는 대신 명확한 307과 303이 등장
  • 307 → 메서드가 변하면 안 됨
  • 303 → 메서드가 GET으로 변경
  • 307과 303 사용을 권장하지만 이미 302를 기본값으로 사용
  • 304 → 응답에 body를 포함하면 안 됨 (로컬 캐시를 사용해야 하므로)
728x90

'BE' 카테고리의 다른 글

미들웨어(Middleware)  (2) 2023.10.13