일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Not Modified
- must revalidate
- 프록시 캐시 서버
- 세션타임아웃설정
- resolveArgument
- 쿠키보안문제
- no cache
- 세션만들어보기
- 프록시객체
- http
- HTTP API
- 양쪽 모두 값 설정
- www-Authenticate
- 인증체크
- hikaricp
- supportParameter
- 조건부요청
- 캐시
- Expires
- 300
- 검증헤더
- 쿠키생명주기
- Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
- UrlResource
- 서블릿필터
- HTTP상태코드
- max age
- gradle오류
- 서블릿http세션
- etag
- Today
- Total
목록300 (2)
복습을 위한
영구리다이렉션과 다르게 검색엔진에서 url을 변경하면안된다. 다음에 어떻게 될 지 모르기 때문이다. 302 303은 비슷한데 실무에선302를 사용한다. 별 문제는 없다. PRG패턴을 알아보자. 상품을 주문하고 주문하기 버튼을 누른다고 하자. 그럼 post메서드로 서버로 내 데이터가 넘어갈 것이다. 자 그런상태에서 결과가 남아있다. 거기서 웹브라우져를 새로고침하면 어떻게 될까? post데이터가 한번 더 들어가서 서버에 중복주문이 들어갈 수도 있다. 요청했던 것을 새로고침해서 새로고침도 post요청이 또 되버리는 것이다, 이것을 해결해야한다.! PRG 사용 전부터 보자. 주문데이터가 요청이 와서 딱 저장이 됐다. 근데 클라이언트에서의 마지막 요청이 무엇이었나? 주문이었다. 실수로 새로고침누르면 마지막 요청을..
여기서 유저 에이전트는 웹브라우져를 말한다. 서버가 '너의 요청을 완료하려면 추가적인 작업이 필요해' 하고 전달하는 코드이다. 리다이렉션 이해 • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트) 원래 페이지에서 url이 바뀌었다고 하자. 하지만 원래 사용자들은 원래 url을 치고 들어갈 경우가 많을 것이다. 서버입장에선 그럼 어? 이제 안쓰는 건데 하고 클라이언트의 웹브라우져에게 알려준다. 그럼 웹브라우져가 어300대 코드고 location헤더 필드가 있네? 하고 스스로 url을 바꾸고 새로운 경로로 다시 요청을 한다. 서버가 그리고 다시 200번대 코드를 응답하는 것이다. 리다이렉션의 종류에는 크게 3가지가 있다. 방금 예시를 든 영구 ..