[Zope-dev] Last-modified and bobobase_modification_time

[Toby Dickenson]

On Thursday 20 Jun 2002 3:18 am, Wei He wrote:
> On Wed, 19 Jun 2002, Toby Dickenson wrote:
> > The only thing Last-Modified can give you over Expires and Cache-Cont=
rol
> > is the possibility of sending a 304 Not Modified response code instea=
d of
> > a 200.
> >
> > If the response is cheap to calculate and transmit then a 200 may not=
 be
> > much more expensive than a 304, and you are correct that maintaining =
an
> > accurate last-modified may not be cost-effective.
> >
> > However, if the response is expensive to transfer (that is, large) or
> > expensive to calculate, then a 304 may be a significant saving.
>
> You just gave a clear explaination of how Last-Modified will influence =
the
> transfer. Let's see if everyone get this:
>
> If maintaning last-modified header is cheap, give an accurate result.

Yes

> If
> not, disable it to the client by sending an expire time in the past or
> something.

No. Just send neither of Last-Modified or Expires.

> In either case, Zope's current implementation needs to be
> changed. Because it will give the client a false impression that a page=
 has
> not changed but actually it did.

What part of Zope gets this wrong?

> > > If I understand correctly, the Expires header can only give the
> > > client an impression how ofter a page is updated.
> >
> > No, it is the opposite of that. It says how long you can assume it wi=
ll
> > not change.=20

> Aren't they the same? What I meant is the header doesn't guarantee that=
 a
> page won't change before the coming expire time.

It tells clients that they can assume it will not change.

(It would be impossible to guarantee that the page will not change, but t=
his=20
header is as close to a guarantee that you can give)

> So using this header won't
> help a client from getting an out-of-date page. The two meaningful uses=
 of
> this header I can think of are:
>
> 1. Give an expire time in the past to force a client give up its cache.

You only ever need to set an expires time in the past if you are setting=20
Last-Modified, but want to inhibit caching.

In your case the right thing to do is *not* set Last-Modified.

If you do want to set Last-Modified, then RFC2616 provides better solutio=
ns=20
than setting Expires in the past (which is really just a pre-RFC2616 hack=
).=20
Check out Cache-Control:must-revalidate or Cache-Control:no-cache.

> 2. Set an expire time a fixed period in the future, say 24 hours,
>    to instruct the client that the page is updated daily.

Yes. That is a good use of Expires.

(Minor detail; dont set it to '24 hours in the future'. set it to '9AM=20
tomorrow morning'. Otherwise a response cached just before your daily upd=
ate=20
will not be revalidated until 24 hours later. If you really want to say '=
some=20
time in the future' then Cache-Control:max-age=3DXXXX is more explicit.)