httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_cache with Cache-Control no-cache= or private=
Date Wed, 13 Mar 2013 17:20:10 GMT
On 11 Mar 2013, at 12:50 PM, Yann Ylavic <ylavic.dev@gmail.com> wrote:

>> The way I read the spec, "the specified field-name(s) MUST NOT be sent in the response
to a subsequent request without successful revalidation with the origin server". What this
means is that if the specified field names are found to be present in the cached response,
then the origin server needs to be given the opportunity to update these fields through a
conditional request. In the current cache code, we return 0 meaning "this is stale, revalidate",
and a conditional request is sent to the origin. We hope the origin sends "304 Not Modified",
with updated headers corresponding to the fields.
> 
> Ok, I see your point, and this is surely the right reading of the rfc,
> but there is necessarily a difference between no-cache and
> no-cache="<header(s)>", particularly with the handling of that (stale)
> header(s).
> 
> For what I understand now, if the origin does not send (one of) the
> header(s) in its 304 response, the stale header(s) "MUST NOT" be
> served.

I don't read it that way from the spec, I think it all comes down to the phrase "without successful
revalidation with the origin server". I read it as "without successful revalidation [of the
whole request] with the origin server". In other words, the origin server sent the original
header, if the origin server doesn't update the header in the 304 response then it means "I've
had my opportunity to revalidate the entity, current cached value is fine, send it".

Roy ultimately would be able to answer this?

Regards,
Graham
--


Mime
View raw message