`expires` http 헤더는 여러 콜드 캐시 요청에서 일관성이 있어야합니까?

Question

나는 종류의 커스텀 웹 서버를 구현하고 있습니다. 만료 된 헤더 지원을 추가하려고합니다. 그러나 나는 그것을 정확히 구현하는 방법에 대해 조금 확신하지 못합니다.

서버에서 동일한 변하지 않은 리소스에 여러 개의 콜드 캐시 요청이 이루어지고 서버가 다른 만료 헤더를 반환 한 경우 (예 : 상대 시간을 사용하여 만료 날짜의 정확한 값을 계산하여 요청 시간으로부터 +6 시간), 그렇습니다. 그 사이의 모든 프록시 서버의 캐시를 무효화합니까? 아니면 (사양에 따라) 발생하는 것이 불가능합니까?

그렇습니다 Expires HTTP 헤더는 여러 콜드 캐시 요청에서 일관성을 유지해야합니까?

Answer 1

좋아, 신경 쓰지 마, 관련 정보를 찾았습니다. 캐시 재 방문 및 재 장전 컨트롤 섹션의 섹션 HTTP 사양

기본적으로 원하는 모든 유효성 검사기에 서비스를 제공 할 수 있지만, 그러한 경우 프록시는 자신의 캐시와 프록시와 통신하는 다양한 사용자 에이전트에서 다른 유효성 검사기 세트를 가질 수 있음을 알고 있어야합니다. 그들은 당신에게 하나를 보내도록 선택할 수 있으며, 그것은 최종 사용자에게 정확하거나 가장 최적의 것이 아닐 수도 있습니다. 그러나 사양에서 "최상의 접근 방식"이 제안되었습니다.

나는 이것이 덮어야한다고 생각한다 Expires ETAG뿐만 아니라 헤더, 캐시 제어 및 What Not.

---

누구나 관심이있는 경우 관련 발췌문이 있습니다.

중간 캐시가 최대 age = 0 지시문을 통해 자체 캐시 항목을 재평가하고 클라이언트가 요청에 자체 유효성 검사기를 제공 한 경우, 제공된 유효성 검사기는 현재 캐시에 저장된 유효성 검사기와 다를 수 있습니다. 기입. 이 경우 캐시는 의미 론적 투명성에 영향을 미치지 않고 자체 요청을하는 데있어 유효성 검사기를 사용할 수 있습니다. 그러나 유효성 검사기의 선택은 성능에 영향을 줄 수 있습니다. 가장 좋은 방법은 중간 캐시가 요청시 자체 유효성 검사기를 사용하는 것입니다. 서버가 304 (수정되지 않음)로 응답하면 캐시는 현재 검증 된 사본을 200 (OK) 응답으로 클라이언트에 반환 할 수 있습니다. 그러나 서버가 새 엔티티 및 캐시 유효성 검사기로 응답하면 중간 캐시는 강력한 비교 함수를 사용하여 리턴 된 캐시를 클라이언트의 요청에 제공된 것과 비교할 수 있습니다. 클라이언트의 유효성 검사기가 Origin 서버와 같으면 중간 캐시는 단순히 304 (수정되지 않음)를 반환합니다. 그렇지 않으면 200 (OK) 응답으로 새 엔티티를 반환합니다. 요청에 캐시가없는 지시문이 포함 된 경우 최소 프레쉬, 최대 스테일 또는 최대 연령이 포함되어서는 안됩니다.