[모든 개발자를 위한 HTTP 웹 기본 지식] 6. HTTP 상태코드 - 3XX 리다이렉션

인프런 김영한님 [모든 개발자를 위한 HTTP 웹 기본 지식] 강의를 듣고 정리한 내용입니다.😊😊

 

1. 3XX (Redirection)

- 요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치가 필요

 

• 300 Multiple Choices (거의 안씀)

• 301 Moved Permanently

• 302 Found

• 303 See Other

• 304 Not Modified

• 307 Temporary Redirect

• 308 Permanent Redirect

 

 

2. 리다이렉션 이해 

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

 

 

👉 자동 리다이렉트 흐름

1) 클라이언트가 GET /event 페이지를 서버에 요청한다.  

2) /event 페이지는 더이상 사용하지 않으므로 서버에서는 상태코드 301과 Location: /new-event 페이지를 응답한다.

3) 웹 브라우저에서 /event -> /new-event 경로로 자동 리다이렉트 한다.

4) 클라이언트가 /new-event 를 서버에 요청 한다. 

5) 서버는 상태코드 200 과 /new-event 에 대한 리소스를 담아 응답한다.

 

 

👉 종류 

1) 영구 리다이렉트 - 특정 리소스의 URI가 영구적으로 이동

   ex) /members -> /users

   ex) /event -> /new-event

2) 일시 리다이렉트 - 일시적인 변경 

  - 주문 완료 후 주문 내역 화면으로 이동 

  - PRG : Post/Redirect/Get

3) 특수 리다이렉션 

  - 결과 대신 캐시를 사용 

 

 

👉 영구 리다이렉션 - 301, 308

- 리소스의 URI가 영구적으로 이동

- 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지

- 301, 308은 같은 기능이다.

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

- 308 Permanent Redirect : 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

 

 

1) 영구 리다이렉트 - 301 Moved Permanently

- 클라이언트가 메세지 바디에 리소스를 담아 POST /event 를 서버에 요청하면

- 서버는 메세지 바디를 제거하고 301 코드와 Location에 /new-event를 담아 응답한다.

- 웹 브라우저의 URL이 자동 리다이렉트 되고

- 클라이언트는 메시지를 제거하고 GET /new-event 를 서버에 요청한다.

- 서버는 200 코드와 /new-event 의 리소스를 응답한다.

-> 이벤트 페이지에서 회원 정보를 등록하려고 했으나, 메시지 바디가 제거된 채로 자동 리다이렉트 되어 입력한 정보가 날라가 처음부터 회원 정보를 다시 입력해서 등록해야 한다.

 

2) 영구 리다이렉트 - 308 Permanent Redirect

- 클라이언트가 메세지 바디에 리소스를 담아 POST /event 를 서버에 요청하면

- 서버는 메세지 바디를 제거하고 308 코드와 Location에 /new-event를 담아 응답한다.

- 웹 브라우저의 URL이 자동 리다이렉트 되고

- 클라이언트는 메시지를 유지해서 POST /new-event 를 서버에 요청한다.

- 서버는 200 코드와 /new-event 의 리소스를 응답한다.

-> 이벤트 페이지에서 회원 정보를 등록하면 자동 리다이렉트 되어 입력한 정보가 유지되어 회원 정보가 정상 등록된다.

 

💡 실무에서는 거의 308은 사용하지 않는다. /event 에서 /new-event로 바뀌게 될 경우, 내부적으로 전달되어야 할 데이터도 변경되기 때문에 POST로 요청을 받아도 리다이렉트시 GET으로 바뀌는게 맞다.

 

 

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

- 리소스의 URI가 일시적으로 변경

- 따라서 검색 엔진 등에서 URL을 변경하면 안된다. 

- 302, 307, 308 기능이 거의 다 똑같다.

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

- 307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)

- 303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경 

 

 

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

POST로 주문 후에 웹 브라우저를 새로 고침하면, 중복 주문이 될 수 있다. 이것을 해결하기 위해 PRG를 사용한다.

- POST로 주문후에 새로 고침으로 인한 중복 주문 방지

- POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트

- 새로고침해도 결과 화면을 GET으로 조회

- 중복 주문 대신에 결과 화면만 GET으로 다시 요청

- PRG 이후 리다이렉트시 URL은 이미 POST -> GET으로 리다이렉트 되어 새로 고침 해도 GET으로 결과 화면만 조회된다.

 

 

1) PRG 사용전 

- 클라이언트가 마우스 1개 주문을 한다. 

- 서버는 DB에 마우스 1개를 저장한다.

- 200 OK HTML 주문완료를 보낸다.

- 실수로 결과화면에서 새로 고침한다. 

- 클라이언트에서 서버로 POST 새로 주문을 요청한다. 

- 서버는 DB에 마우스 1개를 저장한다 

- 주문 완료 된다. 

 

2) PRG 사용후

- 클라이언트가 마우스 1개 주문을 한다.

- 서버는 DB에 마우스 1개를 저장한다.

- 서버에서는 상태코드 302 Found와 Location: 정보를 응답한다. 

- 클라이언트는 자동 리다이렉트를 하여 GET /order-result를 요청한다. 

- 서버는 200 OK HTML 주문완료 화면을 응답한다.

- 사용자가 실수로 새로고침해도 GET /order-result 결과 화면만 다시 나온다. (중복 주문X)

 

 

💡 정리

- 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

1) 300 Multiple Choices: 안쓴다

2) 304 Not Modified ⭐⭐⭐

- 캐시를 목적으로 사용

- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)

- 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)

- 조건부 GET, HEAD 요청시 사용

 

---

❓ 질문 정리 ❗

Q. 영구 리다이렉트와 일시 리다이렉트의 차이점은 무엇인가요? 

A. 단순 웹 브라우저 입장에서는 영구 리다이렉트와 일시 리다이렉트는 같다.

다만 검색엔진처럼 사용자가 아닌 시스템이 크롤링을 하는 경우를 생각해보면 도움이 된다.

1) 영구 리다이렉트는 검색 엔진이 URL을 변경해도 된다. 

2) 일시 다이렉트는 검색 엔진이 URL을 변경하면 안된다. URL이 일시적으로 변경된 것으로 향후 다르게 변경될 수 있기 때문이다.

[참고] https://www.inflearn.com/questions/137142

[참고] https://www.inflearn.com/questions/189308

 

Q. 브라우저에서 POST 요청을 서버에 하고 클라이언트는 아직 302응답을 받지 못한 상황에서 새로고침을 하는 경우, 중복 주문을 막을 수 없는 건가요?

A. 네. 302만으로는 중복 요청을 완전히 막을 수 없고 서버에서도 중복 요청시 해결방안을 마련해야 한다.

즉, 클라이언트 차원의 중복 요청 방지(PGR) & 서버 차원의 중복 요청 방지(중복된 주문 번호 체크) 모두 필요

[출처] https://www.inflearn.com/questions/181131