일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 검증헤더
- 조건부요청
- http
- must revalidate
- 프록시객체
- 양쪽 모두 값 설정
- Expires
- gradle오류
- Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain
- supportParameter
- 캐시
- HTTP API
- 세션타임아웃설정
- 서블릿http세션
- 서블릿필터
- max age
- 인증체크
- 프록시 캐시 서버
- hikaricp
- www-Authenticate
- resolveArgument
- 300
- UrlResource
- Not Modified
- etag
- 세션만들어보기
- 쿠키생명주기
- HTTP상태코드
- no cache
- 쿠키보안문제
- Today
- Total
목록검증헤더 (2)
복습을 위한

전 시간에 봤듯이 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터를 검증 헤더라고 한다. 전 시간에 본 Last -Modified 말고 ETag라는 것이 있다. 이것은 If -None-Match와 함께 사용된다. 다시 요청한 데이터가 바뀌었으면 200ok, 그대로 써도 된다면 304Not Modifeid이다. 이 시간으로 부터 변경이 일어났냐????????? 클라이언트가 이렇게 if modified since로 묻는다. 변경이 일어나지않았으면 요청이 실패하는 것이니 304Not Modified라고 서버는 응답하고 변경안됐으니 그냥 쓰세요!!하고 말하는 거다. 하지만 데이터가 변경되었다면 서버는 어 맞아 변경되었네!!다시 새로운거 가져가!하고 200ok와 함께 새로운 데이터를 내려준다. 근데 방금 살펴..

캐시유효시간이 초과해서 서버에 다시 요청했을 때 서버의 데이터가 바뀐 상태일 수도 있고 아닌 상태일 수도 있다. 바뀌었다면 당연히 다시 새로운데이터를 받아야겠지만 안바뀌었는데 굳이 다시 다운받아야하나..??유효시간이 지났다고해도?? 재사용할 수가 있다!! 단 당연한말이지만 클라이언트에있는 데이터와 서버데이터가 같아야하고 그것을 증명해야만한다!!! 그래서 검증헤더라는 것이 들어간다! 다시 처음으로 돌아가서 별사진 데이터를 요청한다. 이번에는 서버가 캐시정보와 함께 last modified라는 정보도 함께 응답해준다. 이건 해당 데이터가 마지막에 수정된 시간이다. 최종수정시간이다. 클라이언트는 응답결과를 캐시에 저장하고 60초가 유효하다는 것도 인지하고 있다. 여기서 데이터 최종수정시간정보를 더 더해준다. ..