일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- max age
- HTTP상태코드
- 양쪽 모두 값 설정
- 세션타임아웃설정
- 조건부요청
- 서블릿필터
- Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
- 캐시
- 서블릿http세션
- HTTP API
- UrlResource
- must revalidate
- http
- hikaricp
- Expires
- resolveArgument
- 300
- 프록시 캐시 서버
- www-Authenticate
- no cache
- 검증헤더
- etag
- Not Modified
- gradle오류
- 쿠키보안문제
- 세션만들어보기
- 쿠키생명주기
- supportParameter
- 인증체크
- 프록시객체
- Today
- Total
복습을 위한
3xx - 리다이렉션 영구 리다이렉션 본문
여기서 유저 에이전트는 웹브라우져를 말한다. 서버가 '너의 요청을 완료하려면 추가적인 작업이 필요해' 하고 전달하는 코드이다.
리다이렉션 이해
• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
원래 페이지에서 url이 바뀌었다고 하자. 하지만 원래 사용자들은 원래 url을 치고 들어갈 경우가 많을 것이다. 서버입장에선 그럼 어? 이제 안쓰는 건데 하고 클라이언트의 웹브라우져에게 알려준다. 그럼 웹브라우져가 어300대 코드고 location헤더 필드가 있네? 하고 스스로 url을 바꾸고 새로운 경로로 다시 요청을 한다. 서버가 그리고 다시 200번대 코드를 응답하는 것이다.
리다이렉션의 종류에는 크게 3가지가 있다.
방금 예시를 든 영구 리다이렉션 말고도 일시 리다이렉션과 특수 리다이렉션이있다. 일시 리다이렉션은 주문완료 버튼을 누르고 주문 내역 화면으로 이동될 때를 예로 들 수 있다.
특수리다이렉션은 클라이언트에서 캐시가 있는데 캐시기간이 만료된 것 같을 때 클라이언트가 서버에게 '캐시 만료된 것 같은데 맞아?'하고 캐시데이터를 알려주면 서버가 '그냥 써도 돼. 다시 다운로드 받을 필요없어 캐시해서 조회해' 라고 응답을 하는 것이다.
검색엔진들이 원래 url로 들어갈 것이다. 그런데 영구적으로url이 바뀌었으면 원래거를 버리고 새롭게 바뀐 url을 써야한다.
301 308은 비슷하다. 근데 차이가 조금 있다. post로 요청이 왔다고 했을 때 메서드와 본문이 변하냐 변하지않느냐 차이다.
301의 경우이다.
post로 유저정보를 서버로 보냈을 때를 보자. url이 새로 바뀌었다하면 이런식으로 301은 메서드가 바뀌거나 본문이 삭제될 수 있다. 아마 새로운 페이지나 새로운 폼 페이지(다시 입력해야되는........(본문이 삭제됐으니))가 나올 것이다.
그러한 불편함을 308로 해결한다. 308의 경우라면 클라이언트에서 서버로 다시 보낼 때 메서드와 본문을 유지한다.
사실 실무적으로는 이렇게 사용하지않는다. url이바뀐다면 내부적으로 전달해야하는 데이터가 다 바뀌어버린다. 그래서 post로 와도 웬만하면 다시get으로 돌리는 경우가 많다. 그래서 308은 거의 사용안한다. 사실 301도 별로 사용안한다. 뒤에 나오는 일시적인 리다이렉션을 자주사용한다.
참고
'http 상태코드' 카테고리의 다른 글
4XX, 5XX (0) | 2024.01.14 |
---|---|
3xx 일시적리다이렉션, PRG (1) | 2024.01.11 |
http상태코드, 2xx (0) | 2024.01.11 |