HTTP - 3xx 리다이렉션

3xx - 리다이렉션(Redirection)

요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요할 때 오는 응답 코드다.

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

300번은 거의 안 쓰고, 301 ~ 308까지가 중요하다.

리다이렉션 이해

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)

기존 /event를 더이상 사용하지 않고 /new-event를 사용하기로 한다.
사용자들이 북마크 등을 통해서 /event를 통해 페이지를 접속할 때 클라이언트에서 서버로 GET 메소드를 통해 요청을 하면 서버는 301 Moved Permanetly와 Location: /new-event를 준다.
이 때 클라이언트는 3xx 코드에 Location을 보고 해당 URL로 GET 메소드로 서버에 다시 요청 하고 서버는 새로운 페이지를 응답한다.

종류

• 영구 리다이렉션
  • 특정 리소스의 URI가 영구적으로 이동
    • 예 : /members -> /users
    • 예 : /event -> /new-event
• 일시 리다이렉션
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG : POST/Redirect/GET
• 특수 리다이렉션
  • 결과 대신 캐시를 사용
    • 클라이언트가 캐시 기간이 만료된 거 같아 캐시에 대한 정보를 다시 요청할 때 서버가 해당 캐시에서 정보를 얻으라는 응답을 보내는 경우

영구 리다이렉션 301, 308

• 리소스의 URI가 영구적으로 이동했다는 뜻
• 원래의 URL을 사용하면 안 된다.
  • 검색 엔진 등에서도 변경을 인지할 수 있다.
  • 301 Moved Permanently
    • 리다이렉트시 어떤 HTTP 메소드로 요청을 해도 GET으로 변하고, 본문이 제거될 수 있다.(거의 모든 브라우저가 바뀌고 제거됨)
  • 308 Permanent Redirect
    • 301과 기능은 같다.
    • 리다이렉트시 요청 메소드와 본문 유지(처음 POST로 보내면 리다이렉트도 POST를 유지함)

영구 리다이렉션 - 301 Moved Permanently

POST로 요청하고 메시지가 있지만 리다이렉션될 때는 GET으로 바뀌고 메시지도 사라진다.

영구 리다이렉션 - 308 Permanent Redirect

POST로 요청하고 메시지가 있는 경우 리다이렉션을 받아도 URI를 제외한 기존 요청 그대로 다시 요청을 한다.

실무에서는 거의 사용하지 않는다.
URI가 바뀔 때 내부적으로 전달해야 하는 정보가 달라지기 때문에 POST로 와도 GET으로 돌리는 것이 좋다.

일시적인 리다이렉션 302, 307, 303

• 리소스의 URI가 일시적으로 변경된다. (A로 접속해서 B로 갔다가 최종적으로 C로 갈 수 있음)
  • 따라서 검색 엔진 등에서 URL을 변경하면 안됨
• 302 Found
  • 리다이렉트시 어떤 HTTP 메소드로 요청을 해도 GET으로 변하고, 본문이 제거될 수 있다.(거의 모든 브라우저가 바뀌고 제거됨)
• 307 Temporary Redirect
  • 302와 기능은 같다
  • 리다이렉트시 요청 메소드와 본문 유지(요청 메소드를 변경하면 안된다.)
• 302 See Other
  • 302와 기능은 같음
  • 리다이렉트시 어떤 HTTP 메소드로 요청을 해도 GET으로 변경(명확하게 변경됨)

PRG : Post/Redirect/Get 일시적인 리다이렉션 예시

• POST로 주문 후 웹 브라우저를 새로고침하면?
  • 새로고침은 다시 요청
    • 중복 주문이 될 수 있다!

PRG 사용 전 예시

유저의 주문에 대하여 200 OK만 응답한다면 새로고침 했을 때 POST로 서버에 다시 요청하게 되어 중복이 발생한다.
원칙적으로는 서버에서 막아주는 것이 맞지만 클라이언트에서도 막아주는 것이 좋다.

PRG 사용 후 예시

• POST로 주문후에 새로 고침으로 인한 중복 주문 방지
• POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신 결과 화면만 GET으로 다시 요청

• PRG 이후 리다이렉트
  • URL이 이미 POST에서 GET으로 리다이렉트 됨
  • 새로 고침 해도 GET으로 결과 화면만 조회

사용자 입장에서 실수로 새로고침을 해도 결과 화면이 뜨고, POST에서 새로고침을 하면 경고창이 뜨기 때문에 유저 입장에서 시용성이 좋아진다.
서버에서 같은 주문번호면 주문 불가능하게 막는 것은 당연하지만 해당 패턴을 적용하면 서버 오류도 확실하게 줄어드는 효과가 있다.

뭘 쓰지? 302, 307, 303

• 정리
  • 302 Found -> GET으로 변할 수 있다.(거의 변함)
  • 307 Temporary Redirect -> 메서드가 변하면 안됨
  • 303 See Other -> 메서드가 GET으로 변경
• 역사
  • 처음 302 스펙의 의도는 HTTP 메소드를 유지하는 것
  • 그런데 웹 브라우저들이 대부분 GET으로 바꿈(일부는 다르게 동작하기도 함)
  • 그래서 모호한 302를 대신하는 명확한 307, 303이 등장함
• 현실
  • 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용ㅇ
  • 자동 리다이렉션시 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음.

기타 리다이렉션

• 300 Multiple Choices
  • 안쓴다.
• 304 Not Modified
  • 자주 사용함.
  • 캐시를 목적으로 사용한다.
  • 클라이언트가 새로 요청하는 데이터가 기존 데이터랑 똑같을 때 서버는 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
    • 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 함)
  • 304 응답은 응답에 메시지 바디를 포함하면 안 된다.(로컬 캐시를 사용해야 하기 때문)
  • 조건부 GET, HEAD 요청시 사용

인프런 김영한 지식 공유자님의 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식