코진남
HTTP Redirection 본문
리다이렉션 이해
웹 브라우저는 3xx 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동
(리다이렉트)
종류
· 영구 리다이렉션 - 특정 리소스 URI가 영구적으로 이동하는것
·예/members -> /users
·예/event -> /new-event
·일시 리다이렉션 - 일시적인 변경
·주문 완료 후 주문 내역 화면으로 이동
·PRG:Post/Redirect/Get
·특수 리다이렉션
· 결과 대신 캐시를 사용
●영구 리다이렉션 301, 308
·리소스의 URI가 영구적으로 이동
·원래의 URL 사용X, 검색 엔진 등에서도 변경 인지함
·301 Moved permanently
· 리다이렉트시 요청 메서드가 GET 으로 변하고, 본문이 제거 될 수도있다.
·308 Permanent Redirect
·301과 기능은 같음
·리다이렉트 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)
●일시적인 리다이렉션 302,307,303
· 리소스의 URL가 일시적으로 변경
· 따라서 검색 엔진 등에서 URL을 변경하면 안된다.
· 302 Found
·리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될수 있다.(MAY BE)
· 307 Temporary Redirect
·302와 기능은 같다
·리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다)
· 303 See Other
·302와 기능은 같다
·리다이렉트시 요청메서드가 GET 으로변경(MUST NOT)
(302와 303의 차이?)
302는 요청메서드가 변할수도있고 변하지않을수도있지만,
303은 무조건 GET 으로 변경됨
●PRG:Post/Redirect/Get
예시
·POST로 주문후에 웹 브라우저를 새로고침하면 어떻게될까?
·새로고침은 다시 요청
·중복 주문이 될 수 있음.
PRG 사용전
●PRG:Post/Redirect/Get
일시적인 리다이렉션 -예시
·POST로 주문후에 새로 고침으로 인한 중복 주문 방지
·POST로 주문후 주문 결과 화면을 GET 메서드로 리다이렉트
·새로고침을해도 결과 화면을 GET으로 조회
·중복 주문 대신에 결과 화면만 GET으로 다시 요청
●PRG 이후 리다이렉트의 효과
·URL이 이미 POST -> GET으로 리다이렉트가 되버림
·새로 고침 해도 GET으로 결과 화면만 계속 조회하게됨 ( 중복으로 등록이안됨이제)
●뭘써야할지 정리해봄
302,307,303
·302 Found -> Get으로 변할 수 있음
·307 Temporary Redirect -> 메서드가 변하면 안됨
·303 See Other -> 메서드가 GET으로 변경
·역사
·처음 302의 스펙의도는 HTTP 메서드를 유지하는것
·그런데 웹 브라우저들이 대부분 GET으로 바꿔버림
·그래서 모호한 302를 대신하는 명확한 307,303이 등장
·현실
·307,303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기 본값으로 사용중..
·자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 문제없다.
