On May 17, 2007, at 4:37 PM, Justin Erenkrantz wrote:
See the patch I just posted - we should also remove the Date
manipulation too, IMO.
Probably. If Date is added, it should be done by the protocol filter
(mod_proxy) when the message is received, not the cache.
Just for clarification: It is still ok for us to define an cache
internal expiration
date (default / calculated) if there is nothing valid (max-age,
Expires) in the
response, right?
Yes.
We just do not tell the client about it as we do not adjust the
headers in the response
accordingly.
Exactly.
BTW: What about s-max-age here? Shouldn't we use s-maxage instead
of max-age in the
case it is present in the response?
Probably. I've only dug into the max-age case so far - I haven't
chased down the semantics for us supporting s-maxage yet. Though
max-age is explicitly called out as an explicit expiration time, while
s-maxage isn't. Again, I'd need to refresh in my head what s-maxage
is for... -- justin
s-maxage is for use when the value for a shared cache would differ
from the value for a private cache.
s-maxage
If a response includes an s-maxage directive, then for a shared
cache (but not for a private cache), the maximum age
specified by
this directive overrides the maximum age specified by either the
max-age directive or the Expires header. The s-maxage directive
also implies the semantics of the proxy-revalidate directive
(see
section 14.9.4), i.e., that the shared cache must not use the
entry after it becomes stale to respond to a subsequent request
without first revalidating it with the origin server. The s-
maxage directive is always ignored by a private cache.
We should probably have a directive somewhere to indicate whether
we are operating a shared cache (default) or private cache.
....Roy
