일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- UseCase
- status diagram
- 상태다이어그램
- cron
- usecase description
- fan-in fan-out
- 디자인패턴
- prototypepattern 예시 example
- bandit21
- ui 디자인 기본원칙
- nc reverse shell
- sofrware architeture
- telnet
- 객체 상속 속성 인스턴스 메소드 오퍼레이션
- 구조적 설계
- factory metohd pattern
- madia designer ui design
- ssh
- Bandit
- 매크로를 바라보는 시각
- 생성패턴 행위패턴 구조패턴
- gof design pattern
- strucuture charat
- base64
- 암표거래
- 모듈구조도
- 팬인과 팬아웃
- 리버스쉘
- 소프트웨어공학 디자인패턴
- 클래스 관계
- Today
- Total
2.log
리다이렉트(Redirect)과 포워드(Forward) 차이 본문
URL 접속 시 리다이렉트 or 포워드가 일어나면 작업중인 페이지가 전환되는데 리다이렉트는 페이지 전환 주체가 클라이언트, 포워드는 서버임
이 때, 클라이언트가 주체가 되면 처음 접속 요청한 URL이 아닌 서버에서 응답받은 다른 URL로 재요청을 보내야 하지만 서버가 주체가 되면 클라이언트측에서 요청정보 변경 할 필요 없이 서버측 내부 동작을 통해 최종 응답 바로 받을 수 있음
Redirect
서버에서 클라이언트가 요청한 URL에 대한 응답으로 다른 URL로의 재접속 명령(300번대 코드) 보냄
[ex]
- 클라이언트가(브라우저) a 를 요청하면 서버는 redirect b 를 응답함
- 클라이언트는 b 로 다시 요청 날리고 서버는 c라는 결과 응답
>> 클라이언트 측에서 요청이 총 2번 발생, 리소스 변경 여부 확인 가능
[특징 및 유의점]
1. URL 변화 확인 가능
2. 웹 브라우저가 다른 URL 에 새로운 요청을 보내는 것이기에 Request / Response 객체 공유 x
3. Req / Res 객체 공유하지 않기에 CREATE, UPDATE, DELETE 처리 가능
Forward
클라이언트가 재요청 해야하는 리다이렉트와 달리 서버 내부에서 모든 동작 처리함
[ex]
클라이언트가(브라우저) a 를 요청하면 서버 내부에서 a -> b -> c 로 포워딩 된 리소스 확인한 뒤 결과적으로 c 를 응답함
>> 서버측에서 모든 동작을 처리하기 떄문에 클라이언트(웹브라우저)측 요청정보가 그대로 유지됨
[특징 및 유의점]
1. URL 변화 확인 불가
2. Request 객체와 Response 객체를 공유함
3. Req / Res 객체가 공유되기에 READ 와 같은 조회 처리 정도만 하는 것이 좋음
[출처]
https://velog.io/@bongf/learned-redirect-forward
https://twinparadox.tistory.com/613
'HACKING > Bandit+' 카테고리의 다른 글
SSH 키 이용 시 bad permissions: ignore key: 에러가 발생할 경우 (0) | 2023.04.01 |
---|---|
diff 명령어 (0) | 2023.04.01 |
OpenSSL 과 s_client (0) | 2023.03.28 |
Insecure_Client_Initiated_Renegotiation (0) | 2023.03.28 |
HeartBleed 취약점에 대하여 (0) | 2023.03.26 |