일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 스프링 핵심 원리
- Thymeleaf
- 백준
- Greedy
- springdatajpa
- 스프링
- Servlet
- pointcut
- java
- transaction
- 자바
- JPQL
- SpringBoot
- jpa
- Spring Boot
- Exception
- 그리디
- AOP
- 인프런
- db
- Proxy
- QueryDSL
- Android
- 김영한
- 스프링 핵심 기능
- JDBC
- http
- kotlin
- spring
- 알고리즘
- Today
- Total
목록조건 부 요청 (2)
개발자되기 프로젝트
1. 검증 헤더 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터 Last-Modified, ETag 2. 조건 부 요청 헤더 검증 헤더로 조건에 따른 분기 If-Modified-Since: Last-Modified 사용 If-None-Match: ETag 사용 조건이 만족하면 200 OK 조건이 만족하지 않으면 304Not Modified 3. If-Modified-Since 사용 예시 서버측 데이터 미 변경 시 - 캐시 : 2020년 11월 10일 10:00:00 vs 서버 : 2020년 11월 10일 10:00:00 - 해당 조건이 만족하지 않으니 304 Not Modified 및 헤더 데이터만 전송(Body 없음) - 3xx : 리다이렉션? 어디로? 캐시로! 서버측 데이터 변경 시 - 캐시 : ..
1. 캐시 유효 시간이 초과한 경우..? 캐시 유효 시간이 초과하여 서버에 재 요청했을 때 서버는 둘 중 한 가지 상황이다. 서버에서 기존 데이터를 변경함 서버에서 기존 데이터를 변경하지 않음. 2. 서버에서 데이터를 변경하지 않은 경우 캐시 만료 이후에 서버에서 데이터를 변경하지 않음 이 경우에는 캐시를 사용할 수 있을 것 같은데...? 단, 클라이언트의 데이터와 서버의 데이터가 같은지 검증이 필요함. 검증헤더가 필요해 3. 검증헤더, 조건 부 요청 : Last-Modified, If-modified_since 클라이언트의 요청에 대한 응답으로 서버에서 응답을 줄 때 Last-Modified: 2021년 08월 04일 22:00:00 과 같이 마지막으로 수정된 시각 전달 가능. 응답을 받은 브라우저는 ..