[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: