3xx Redirection

3xx Redirection

 

요청을 완료하기 위해 유저의 추가적 조치가 필요한 상황

웹 브라우저는 3xx 응답의 결과에 location header 가 존재 시 해당 location으로 이동하며 이를 redirect라 한다.

 

영구 redirection - 특정 리소스가 영구적으로 이동하는 케이스

• 원래의 url을 사용하지 않는다.
• 검색엔진 등에서도 변경을 인지한다.
• 301 moved permanently
  • 리다이렉트시 요청 메서드가 get으로 변하고 본문 제거 될 수도 있음 (MAY)
• 308 permanent redirect
  • 301과 기능은 같으나 리다이렉트 요청시 메서드와 본문 유지 (Post -> Post)

 

• 실무에선 POST로 와도 GET으로 돌림 (308 잘안씀 301 쓴다)
• Ex) /members -> /users

 

일시적인 redirection - 일시적인 변경 (실무에서 가장 많이 쓰인다)

• 리소스의 url가 일시적으로 변경
• 따라서 검색 엔진 등에서 url을 변경하면 안된다.
• 302 Found (메서드를 유지하는 것이 302 스펙의 의도)
  • 리다이렉트 요청시 메서드가 get으로 변하고 본문이 제거 될 수 도 있음 (MAY)
  • 302 Temporary Redirect
  • 302와 기능은 같으나 리다이렉트시 요청 메서드와 본문 유지(요청 메서드 변경 x)
• 303 See Other
  • 302와 기능은 같으나 리다이렉트시 요청 메서드가 Get으로 변경
• 주문 완료 후 주문 내역 화면으로 이동
• PRG : Post/Redirect/GET
  • POST로 주문 후 새로 고침으로 인한 중복 주문 방지
  • POST로 주문 시 주문 결과 화면을 GET 메서드로 리다이렉트
  • 새로고침해도 결과 화면을 GET으로 조회 -> 중복 주문 대신 결과화면만 요청
    • ex) Post로 주문 후 웹 브라우저에서 새로고침 (PRG 전)
      • 새로고침은 다시 요청을 보낸다 -> 중복 주문이 될 수도 있음.
    • ex) Post로 주문 후 웹 브라우저에서 새로고침 (PRG 적용)
      • 새로고침으로 보내도 메서드가 변동되어 다른 작용을 하게됨 -> 중복 주문 방지
• 모호한 302를 대신하는 명확한 307,303 이등장(301 대응으로 308)
• 303,307을 권장하지만 현실적으로 많은 애플리케이션 라이브러리들이 302를 기본 값으로 사용한다. 

특수한 redirection - 결과 대신 캐시를 사용 하는 경우

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