HTTP 웹 기본 지식 - 3xx - 리다이렉션1

3xx - 리다이렉션1

Redirection은 클라이언트가 서버에 요청을 했을 때,
서버가 "이 요청을 완료하려면 뭔가 추가적인 작업이 필요해!" 라고 하고선 클라이언트에게 다시 보내는 것이다.

3XX (Redirection)은 요청을 완료하기 위해 유저 에이전트의 추가 조치가 필요하다.

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

300번대는 300번은 거의 쓰지 않고, 301~308번이 중요하다.

 

 

먼저, 가장 중요한 리다이렉션이 뭔지 알아보자.

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동하는데, 이것을 "리다이렉트"라고 한다.

 

예제를 보자.

예를 들어서, 경로가 /event인 이벤트 페이지가 있을 때,
예전에 이벤트 페이지를 여러군대에 뿌려놓았다고 가정했을 때,
더이상 /event 를 안쓰고, 새로운 이벤트 페이지인 /new-event 페이지를 사용하기로 했다면 어떻게 해야할까?

기존 사용자들은 /event를 북마크를 해놓았을 수도 있고, 기존의 링크가 여러군대 공유되어있을 수도 있다.

그러면, 그런 사용자들은 /event라고 쳐서 들어올 것이다.
그렇게 되면, 그 사용자들은 GET /event를 요청한다.

그러면 서버 입장에선, "이거 /event를 더이상 사용하지 않는데..? "라고 해서
클라이언트에게 "이 경로는 이제 안쓰고 /new-event로 바뀌었어!!"라고 알려주면 된다.

HTTP/1.1 301 Moved Permanently
Location: /new-event

301코드를 쓰고, Moved Permanently라고 해서 영원히 이동했어 라고 알려준다.
Location의 위치를 /new-event 라고 알려주면,

이 클라이언트의 웹브라우져가, 응답을 보고
"어?? 300대 시리즈고, Location 헤더 필드가 있네!?"라고 하고선
이 경로로 웹브라우저창의 URL을 Location 경로로바꾸고 접속을 요청 해준다.

그러면 클라이언트의 웹브라우저가 바뀐 URL경로로 서버에 다시 요청을 한다.

그러면서
GET /new-event HTTP/1.1
라고 보내면,

서버는 "아! new-event 페이지 GET요청이 왔구나!"라고 하고 new-event 페이지에 대한 응답 HTML을 클라이언트에 내려준다. 그러면 클라이언트의 웹브라우저에 /new-event 페이지가 열린다.

클라이언트 입장에서는 이 과정이 너무빨라서 사실 인식을 잘 못한다.

이러한 리다이렉션에는 크가 3가지 종류가 있다.

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
  • 예) /members → /users
  • 예) /event → /new-event
• 일시 리다이렉션 - 일시적인 변경
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG : Post/Redirect/Get  (굉장히 자주쓰는 패턴임)
• 특수 리다이렉션
  • 결과 대신 캐시를 사용

 

영구 리다이렉션은 301, 308 코드가 있다.

• 리소스의 URI가 영구적으로 이동
• 원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
• 301 Moved Permanently
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
• 308 Permanent Redirect
  • 301과 기능은 같음
  • 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

이벤트 참여하는것을 가정하자.

만약에 /event에 POST라고 하고 내부 HTML포맷에 사용자 정보를 입력해서 보내면,
이 사용자를 이벤트에 등록한다는 뜻이다.

그러면, HTML FORM에다가 정보를 등록하고 폼으로 전송을 하면 POST로 정보가 입력된다.

그러면 서버에서는 "아..이거 더이상 /event를 안쓰는데../new-event로 바꿔야해."
라고 301로 응답코드를 보낸다.

그러면 클라이언트가 받은 다음에 클라이언트에서 URL의 경로를 /new-event로 바꾼다.
그리고 요청을 하는데, 어떻게 요청을 하냐면,

301은 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (무조건 GET으로 변하고 본문이 제거되는 것이 아니다 라고 스펙에는 표현되어있어서 "될 수 있음"이라고 표현했지만 대부분 GET으로 변한다.)

브라우저들은 거의 구현이 이렇게 되어있다.

그렇다보니, 나는 등록을 하길 원해서 데이터를 POST로 보냈지만, 결과적으로 GET으로해서 /new-event가 날라가고, 메시지 바디부분이 다 사라졋다.

 

그러면 어떻게 되냐면, 그냥 새로운 이벤트페이지에 정보를 다시 입력해야하는 폼이 나오거나, 새로운이벤트페이지 화면이 나오든지 할 것이다. 내가 등록하려고 했던 것을 처음부터 다 다시 시작해야 하는 것이다.

어쨋든 301로 하면 리다이렉트시 요청 메서드가 GET으로 변해서, "new-event 페이지를 보여달라는 거구나!!!" 라고 서버가 인식해서 새로운 뉴이벤트페이지를 보내게된다. 그러면 클라이언트는 "아!!이거뭐야!! 하면서 처음부터 다시 정보를 입력해야 한다."그러고나서 다시 /new-event를 POST로 보내서 등록을 하거나 할 것이다.

 

그러면 308은 어떨까?

301에서 살펴본 문제를 308로 해결할 수 있다.

클라이언트가 서버로 요청을 보낼 때, POST를 사용헀으면,
POST로 /event가 서버로 넘어올 것이다. name=hello&age=20 도 메시지로 넘어왔다.

그런데 서버가 308로해서 클라이언트에게 응답을 보내면,

301과 똑같지만 무슨 차이가 있냐면,

308로 보낸 것은, 클라이언트가 서버로 다시 보낼 때, POST인 것을 유지시켜준다.
그리고 메시지 본문도 유지된다.

그러면 클라이언트에서 다시 POST /new-event로 서버로 보내면,
데이터가 등록이 되고 이벤트 참여되었다는 응답이 나올 것이다.

 

스펙에 있는 내용이라서 언급했지만,

사실 실무에서는 거의 이렇게 사용하지 않는다.

왜냐하면 /event에서 /new-event로 바뀌어버리면,
내부적으로 전달해야 하는 데이터자체도 다 바뀌어버린다.

그렇기 때문에 사실 이런 경우에는 POST로 와도 왠만하면 다시 GET으로 돌려보내곤 한다.