3xx (Redirection)
요청을 완료하기 위해 유저 에이전트(클라이언트의 프로그램, 즉 웹 브라우저)의 추가 조치 필요
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 307 Temporary Redirect
- 308 Permanent Redirect
리다이렉션 이해
- 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)
- 3xx 일때 자동 리다이렉션!
- 이미 /event(옛날 이벤트 페이지) 라는 URL이 퍼졌는데, /new-event(새로 바꾼 이벤트 페이지) 라는 URL로 바꾸고 싶을 때! -> 자동 리다이렉트
- 응답 Moved Permanently : 영원히 경로가 이동을 했다
종류
- 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
- 예) /members -> /users
- 예) /event -> /new-event
- 일시 리다이렉션 - 일시적인 변경
- 주문 완료 후 주문 내역 화면으로 이동
- PRG: Post/Redirect/Get
- 특수 리다이렉션
- 결과 대신 캐시를 사용
영구 리다이렉션
301, 308
- 리소스의 URI가 영구적으로 이동
- 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
- 301 Moved Rermanently
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (MAY)
- 308 Permanent Redirect
- 301과 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지 (처음 POST를 보내면 리다이렉트도 POST 유지)
- 이건 사실상 스펙일 뿐이고, 실무에서는 거의 이렇게 사용하지 않음
- /event -> /new-event 로 바뀌면 내부적으로 전달해야 하는 데이터 자체가 전부 바뀌어 버리기 때문에 POST로 요청 해도 리다이렉트 후 GET으로 변해서 다시 요청하는 편이 낫다.
일시적인 리다이렉션
302, 307, 303
- 리소스의 URI가 일시적으로 변경
- 따라서 검색 엔진 등에서 URL을 변경하면 안됨 -> 사용자가 /event를 검색했는데, 검색 엔진이 /temp-event를 띄워주면 안됨! /temp-event는 일시적인 URI니까!
- 302 Found
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (MAY)
- 307 Temporary Redirect
- 302와 기능은 같음
- 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다) (MUST NOT)
- 303 See Other
- 302와 기능은 같음
- 리다이렉트시 요청 메서드가 GET으로 변경
PRG: Post/Redirect/Get
일시적인 리다이렉션 - 예시
- POST로 주문 후에 웹 브라우저를 새로고침하면?
- 새로고침은 다시 요청 (POST를 그대로 가지고 있다가, 다시 POST 요청)
- 중복 주문이 될 수 있다.
위의 그림은 PRG 사용 전!
- POST로 주문 후에 새로 고침으로 인한 중복 주문 방지
- POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
- 새로고침해도 결과 화면을 GET으로 조회
- 중복 주문 대신에 결과 화면만 GET으로 다시 요청
위의 그림은 PRG 사용!
- PRG 이후 리다이렉트
- URL이 이미 POST -> GET으로 리다이렉트 됨
- 새로 고침 해도 GET으로 결과 화면만 조회
그래서!!!!! 뭘 써야 하나요?
302, 307, 303
잠깐 정리
- 302 Found -> GET으로 변할 수! 있음
- 307 Temporary Redirect -> 메서드가 변하면 안됨
- 303 See Other -> 메서드가 GET으로 변경
역사
- 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것
- 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림(일부는 다르게 동작)
- 그래서 모호한 302를 대신하는 명확한 307, 303이 등장함(301 대응으로 308도 등장)
현실
- 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음
기타 리다이렉션
300 304
- 300 Multiple Choices: 안쓴다.
- 304 Not Modified
- 캐시를 목적으로 사용
- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
- 클라이언트야, 캐시에 있는 데이터를 써!!
- 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
- 조건부 GET, HEAD 요청시 사용
추가 지식
리다이렉트와 포워딩?
- Redirect는 서버에서 Http Header에 Location을 내려줘서 브라우저에서 Location을 읽어서 다시 요청한다.
- 그에반해 Forwarding은 서버 내부에서 다른 url로 접근하여 응답을 클라이언트에 전달한다. 이때 응답 메세지에 이동한 url 경로가 포함되지 않는다. 따라서 포워드 된 경로는 HTTP 메시지에서 확인할 수 없다.
- 개발자가 굳이 forward된 url을 http message에 담아줄 수는 있지만, 일반적인 경우는 아니다.
