[웹] 검증 헤더와 조건부 요청

캐시 시간 초과로 서버에 다시 요청하면 두가지 상황이 나타난다. 첫번째는 서버에서 기존 데이터를 변경하는 것, 두번째는 서버에서 기존 데이터를 변경하지 않는 것이다.

만약에 두번째 상황이라면, 다시 다운받기 아깝다. 그래서 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다. 그것이 검증 헤더이다.

Last-Modified 라는 검증 헤더를 통해 데이터가 마지막에 수정된 시간을 알 수 있다. 이것을 서버로 부터 받아서 데이터와 마지막 수정 날짜를 저장해둔다.

다음 요청에서 if-modified-since 라는 조건부 요청 헤더로 클라이언트에서 가지고 있는 데이터의 최종 수정일과 서버의 데이터 최종 수정일을 비교하고 수정이 안됐다면 서버에서 304 Modified를 보내어 원래 가지고 있던 것을 사용해도 된다고 말한다.

그래서 클라이언트는 데이터를 재사용한다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디 X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

검증 헤더와 조건부 요청

캐시 시간 초과로 서버에 다시 요청하면 두가지 상황이 나타난다. 첫번째는 서버에서 기존 데이터를 변경하는 것, 두번째는 서버에서 기존 데이터를 변경하지 않는 것이다.

만약에 두번째 상황이라면, 다시 다운받기 아깝다. 그래서 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다. 그것이 검증 헤더이다.

Last-Modified 라는 검증 헤더를 통해 데이터가 마지막에 수정된 시간을 알 수 있다. 이것을 서버로 부터 받아서 데이터와 마지막 수정 날짜를 저장해둔다.

다음 요청에서 if-modified-since 라는 조건부 요청 헤더로 클라이언트에서 가지고 있는 데이터의 최종 수정일과 서버의 데이터 최종 수정일을 비교하고 수정이 안됐다면 서버에서 304 Modified를 보내어 원래 가지고 있던 것을 사용해도 된다고 말한다.

그래서 클라이언트는 데이터를 재사용한다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디 X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

검증 헤더와 조건부 요청

캐시 시간 초과로 서버에 다시 요청하면 두가지 상황이 나타난다. 첫번째는 서버에서 기존 데이터를 변경하는 것, 두번째는 서버에서 기존 데이터를 변경하지 않는 것이다.

만약에 두번째 상황이라면, 다시 다운받기 아깝다. 그래서 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다. 그것이 검증 헤더이다.

Last-Modified 라는 검증 헤더를 통해 데이터가 마지막에 수정된 시간을 알 수 있다. 이것을 서버로 부터 받아서 데이터와 마지막 수정 날짜를 저장해둔다.

다음 요청에서 if-modified-since 라는 조건부 요청 헤더로 클라이언트에서 가지고 있는 데이터의 최종 수정일과 서버의 데이터 최종 수정일을 비교하고 수정이 안됐다면 서버에서 304 Modified를 보내어 원래 가지고 있던 것을 사용해도 된다고 말한다.

그래서 클라이언트는 데이터를 재사용한다.

정리

• 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면
• 304 Not Modified + 헤더 메타 정보만 응답(바디 X)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책