검증 헤더와 조건부 요청2

전 시간에 봤듯이 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터를 검증 헤더라고 한다.  

전 시간에 본 Last -Modified 말고 ETag라는 것이 있다.  

이것은 If -None-Match와 함께 사용된다. 다시 요청한 데이터가 바뀌었으면 200ok, 그대로 써도 된다면 304Not Modifeid이다. 

이 시간으로 부터 변경이 일어났냐????????? 클라이언트가 이렇게 if modified since로 묻는다.  

변경이 일어나지않았으면 요청이 실패하는 것이니 304Not Modified라고 서버는 응답하고 변경안됐으니 그냥 쓰세요!!하고 말하는 거다.

하지만 데이터가 변경되었다면 서버는 어 맞아 변경되었네!!다시 새로운거 가져가!하고 200ok와 함께 새로운 데이터를 내려준다. 

 

근데 방금 살펴본 Last Modified ,If Modified Since이 세트 헤더는 단점이있다. 초단위 미만으로는 시간 조정이 불가능하다. 그리고 날짜 기반의 정해진 로직을 사용해야한다.  

그리고 서버에서 데이터를 변경했다해도 a -> b       b->a  이런식으로 a에서b로 변경되었다가 다시 a로 변경이 되었을 경우가 있다. 그럼 사실 컨텐츠는 변한게 없다. 마치 crtl+c 복사를 하고 crtl+z로 실행취소하고 crtl+c를 다시 하는 것처럼..

하지만 어쨌든 데이터를 수정하긴 한거니깐 최종수정시간은 변화가 되어있을 것이다.....새로 다운받아야한다,,,,,,,,,,,

 

이런 상황에 서버에서 완전하게  캐시 메커니즘을 컨트롤 할 수 있는 방법이 있다!!!

 

그것이 바로 Etag이다 (Entity Tag)

서버에서 날짜가 아니라 캐시용데이터에 임의의 고유한 버전 이름을 달아둘 수가 있다. 버전이나 해시같은 것 말이다.

해시는 파일이 동일하면 똑같은 결과가 나온다. 

단순하다.  클라이언트 입장에서Etag만 보내서 같으면 유지하고 다르면 다시 받는거다!!

 

역시 별사진 예시를 보자 이번에는 서버에서 Etag를 내려준다. 

클라이언트는 헤더정보를 포함 응답결과를 캐시에 저장한다. 

유효시간이 다 되어 다시 서버에 요청을 한다. if None Match 헤더정보와 함께 말이다. 만약 매치가 안되면????하고 묻는다. 매치가 안되니??서버에게 묻는다. 

 

서버의 데이터가 수정이 되지않았다면????????? 매치가 안되니???라는 요청이 실패한거다. 

304코드와 함께 바디없이 헤더만 보내주는 것이다. 캐시 재활용해서 써라! 하면서 말이다. 

 

클라이언트는 응답을 받고 갱신해서 다시 사용한다! 

캐시 제어 로직을 서버에서 완전히 관리하는 것이다. Etag사용시 클라이언트는 캐시 메커니즘을 모른다. 

 

 

 

 

출처

https://www.inflearn.com/course/lecture?courseSlug=http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC&unitId=61385&tab=curriculum