Re: Expires: headers for Packages.gz, Sources.gz
On Fri, Feb 09, 2001 at 10:15:02PM -0700, Jason Gunthorpe wrote:
> On Sat, 10 Feb 2001, Matt Zimmerman wrote:
> > Yes, but Squid (for example) will not forward an IMS request to the server
> > if the cached object is fresh.
>
> Then it is in violation of RFC2068, secion 14.9:
>
> The Cache-Control general-header field is used to specify directives that
> MUST be obeyed by all caching mechanisms along the request/response chain.
> [..] max-age Indicates that the client is willing to accept a response
> whose age is no greater than the specified time in seconds. Unless
> max-stale directive is also included, the client is not willing to accept
> a stale response.
>
> Which is the header APT sends, with a 1 day old setting by default. If you
> set that to 0 say (there is a configuration setting), then squid is required
> to never return a non-validated response.
Ah, I thought you were referring to If-Modified-Since, not Cache-Control:
max-age. However, max-age=1 day will not have the same effect as the Expires:
header I proposed. Unless I am mistaken, max-age refers to the maximum time
since the object was last refreshed (newly retrieved or IMS/Not Modified).
This means that if Packages.gz is downloaded 23 hours after it was modified, a
client's request of max-age=86400 will still get the old object for up to a day
later. Whereas, if the object was set to expire 1 day after its file
modification time, it would become stale right around the time the new version
comes in. It could even expire a little sooner to be safe.
--
- mdz
Reply to: