[Tilecache] http 304 Not Modifies responses ?

Attila Csipa plists at prometheus.org.yu
Wed Jan 2 10:41:32 EST 2008


On Wednesday 02 January 2008 16:15:35 Christopher Schmidt wrote:
> > > In general, I simply use mod_expires on the Apache side to do this for
> > > me: I set the expiration time to 1 month, and it stays in cache for as
> > > long as neccesary.
> >
> > That's very different from I'm doing. I have datasets that change rarely,
> > but when they do, it's critical that the data show by the clients is
> > up-to-date. 
>
> Yep. I understand the motiations for both, but my data (seldom|never)
> changes, so I just use expires headers.

What needs to be noted to others is perhaps that the two can be used together, 
you can still have expires headers AND get a 304 response after the browser 
decides the tile has expired. In fact, the 304 would be a 'freebie' for the 
operators as they don't have to set anything in their server configs.

> I have a feeling that the answer is either: "I've changed the return
> from the diskcache 'get' method to include metadata" -- which breaks the
> Cache class API, such as it exists -- or "I've changed this single
> function call to also return something different which I use to look at
> the file directly" -- which is brekaing an abstraction barrier.
> The former is not an unsolvable problem, but since users acn write their
> own cache classes, it's something we need to be careful with.

Actually, I added a getDate method to Cache, which is implemented in DiskCache 
and gets called from renderTile (meaning it fails gracefully on memcache 
based caches, but see below). All other mods are contained within the Service 
class.

> The latter is a problem because disk caching is *not* the only way tiles

Not sure how elegant this is, but I simply leave off the Last-Modified header 
if the date is unavailable for whatever reason (see above). In fact, I do 304 
handling via an exception - everything goes along as usual, but if we find 
out the browser has the tile - bail out with a 304. 

> can be stored -- there are existing users of the memcached class, for
> example, and they don't have a file on disk to get the information from.

A-Ha ! This is where the ETag info comes in. We can tie the ETag content to 
dates - as memcache does not 'know' when the tile was rendered, we can, on a 
get, also set the etag of a tile and associate a Last-Modified date with it. 
This will obviously vanish on restarting, but results in no harm. A similar 
mechanism can be also used for other cache sources if need be, it's just a 
metter of organizing data, the timestamp of the file just make it easier and 
saves us from generating/maintaining a hash of keys/etags/dates manually.




More information about the Tilecache mailing list