JArchive 프로그래밍 일기

리다이렉션이란? 

요청을 완료하기 위해 클라이언트 프로그램(주로 웹 브라우저)에게 다시 보내는 것

3xx 응답 결과에 Location헤더가 포함되어 있으면 거기에 명시된 URL로 이동한다.

자동 리다이렉트 흐름 예시 

1) 클라이언트 : 이벤트 페이지 /event 요청보냄

2) 서버 : /event 이젠 안씀! 헤더의 Location 필드 실어서 301 코드 응답보냄  Location :/new-event

3) 웹 브라우저가 301코드의 Location 필드를 읽고 URL을  /new-event로 인식. 서버에 /new-event 로 요청보냄 

리다이렉션 3가지 종류 

1. 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동 

2. 일시 리다이렉션 : PRG 패턴. 일시적인 변경 ex) 주문 완료 후 주문 내역 화면으로 리다이렉트 

3. 특수 리다이렉션 : 캐시 만료 여부를 서버에 요청. 캐시를 사용하니까 메시지 바디 쓰면 안됨.

영구 리다이렉션 

301, 308 둘 다 경로가 완전히 바뀌었음을 알려준다. 

리소스의 URI가 영구적으로 이동한다. 검색 엔진 등에서도 변경을 인지한다. 

301: 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수도(MAY)있다. 

308: 리다이렉트 시 요청 메서드와 body의 데이터를 유지한다. 

실무에서는 post로 와도 get으로 돌리는 형태 301로 구현한다. 

새로운 페이지로 가면 페이지의 내용이나 요구하는 데이터가 달라지는 경우가 많기 때문에 post를 유지할 필요가 거의 없기 때문이다. 

일시 리다이렉션 

302를 실무에서 디폴트로 많이 쓴다. 

302는 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도(MAY)있다. 

307 리다이렉트 시 요청 메서드와 본문을 유지한다. 

303 리다이렉트 시 요청 메서드가 GET으로 변경된다. 

[중요] PRG패턴 : Post / Redirect / Get 

Post 로 주문 후에 웹 브라우저를 새로고침 하면 어떻게 될까? 

'새로고침'은 '재요청'과 같다. 따라서 이 경우 새로고침 하면 post를 2번 요청한 것이 되니까 중복 주문이 발생하는 문제가 있다. 

post로 주문 요청 후에, 주문 결과 화면을 get메서드로 리다이렉트 한다. 

이렇게 하면 '새로고침' 해도 post가 아니라 get요청이 되니까 중복 주문을 피할 수 있다. 

그래서 뭘 써야 하나요?

처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었다. 하지만 대부분의 웹브라우저들이 GET으로 바꿔버린다. 

모호한 302를 보완하기 위해 303, 307이 등장한다. 

303, 307을 권장하지만 이미 현실의 많은 애플리케이션 라이브러리들이 302를 디폴트로 사용중이다. 

자동 리다이렉션 시에 GET으로 변해도 되면 302를 써도 문제가 없다. 

기타 리다이렉션 

304 Not Modified 

캐시로 리다이렉트 한다. 엄청 자주 쓴다. 

클라이언트에게 "리소스가 수정되지 않았으니 로컬PC에 저장된 캐시를 재사용하세요" 라고 알리면서 캐시로 리다이렉트 한다. 

캐시로 리다이렉트 하니까 응답에 메시지 바디를 포함하면 안된다. 

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 공부하고 요약했습니다.