[모든 개발자를 위한 HTTP 웹 기본 지식] 7. HTTP 헤더2 (캐시와 조건부 요청) - 캐시 무효화

인프런 김영한님 [모든 개발자를 위한 HTTP 웹 기본 지식] 강의를 듣고 정리한 내용입니다.😊😊

 

1. Cache-Control

💡 확실한 캐시 무효화 응답

Q. 캐시를 적용 안하면 캐시가 안되는것이 아닌가?

A. 캐시를 적용안해도 get 요청인 경우 웹브라우저가 임의로 적용하는 경우도 있다. 

 

1) Cache-Control: no-cache, no-store, must-revalidate

2) Pragma: no-cache

 - HTTP 1.0 하위 호환

 ex) 통장 잔고

 

💡 캐시 지시어(directives) - 확실한 캐시 무효화 

1) Cache-Control: no-cache

- 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)

2) Cache-Control: no-store

- 데이터에 민감한 정보가 있으므로 저장❌ (메모리에서 사용하고 최대한 빨리 삭제)

3) Cache-Control: must-revalidate

- 캐시 만료후 최초 조회시 원 서버에 검증해야함

- 원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)

- must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

4) Pragma: no-cache

- HTTP 1.0 하위 호환

 

 

2. no-cache vs must-revalidate

💡 no-cache 기본 동작

1) 캐시 서버 요청 no-cache를 프록시 캐시로 보낸다. 

2) 프록시 캐시는 no-cache로 받았기 때문에 처리 할 수가 없어 원 서버로 요청한다.

3) 요청을 받은 원 서버는 검증을 한다.

4) 쓸 수 있다면 정상적으로 응답을 해준다. 

⭐ 그렇기 때문에 원 서버(=오리진 서버)라는 단어가 중요하다.

 

💡 no-cache 

1) 캐시 서버 요청 no-cache를 프록시 캐시로 보낸다. 

2) 만약에 프록시 캐시 서버가 순간 네트워크 단절로 원 서버 접근이 불가 할 때

3) 오류 보다는 오래된 데이터라도 보여주자라고 설정이 되어있을 때 

4) 웹 브라우저로 200 OK 응답을 할 수 도 있습니다.  

 

 

💡 must-revalidate

1) 캐시 서버 요청 must-revalidate를 프록시 캐시로 보낸다. 

2) 만약에 프록시 캐시 서버가 순간 네트워크 단절로 원 서버 접근이 불가 할 때

3) 웹 브라우저로 504 Gateway Timeout 응답을 할 수 도 있습니다. 

⭐ 돈과 관련된 결과일 때는 예전 데이터를 보여주는 것보다 보여주지 않는 것이 낫다.❗