[Geoserver-devel] Map caching via http headers

Hello all,

I've recently been poking at ka-map (http://ka-map.maptools.org/) and
got it to serve up its maps with a javascript-only browser-application
backed by the geoserver WMS.

However, it's abundantly clear that this needs caching. Putting squid
in front of geoserver can help tremendously, but squid is very reluctant
to cache anything without proper caching meta-information in the
appropriate http headers.

I learned the (very very small!) bits that I know from
http://www.mnot.net/cache_docs/

I was thinking that since adding caching headers to dynamically
generated maps is probably very bad "default" behavior, this might be
better accomplished by having some kind of "per-map" or "per-dataset"
information which would prompt geoserver to add appropriate
"Cache-Content" headers to an image or WFS response.

Oh, and this would clearly only work with WMS/WFS "KVP-GET" requests, as
caches pretty much ignore POST-ed content. And it seems to make more
sense with WMS than WFS, for that matter.

One way would be something like this:

Allow getmap requests to be specified as follows -
http://my.geoserver.instance/geoserver/wms/getmap?my=get&map=looks&like=this&cache=3600s

This would add the header:
"Cache-Content: max-age=3600s"
to the generated map.

This is slightly clunky, as there are a number of "sub-params" which can
go into Cache-Content (see that page above for details) and really only
solves one very specific form of the caching problem

A different way would be something like this:

For datasets that change infrequently, caching for a long time seems to
be a less "bad" solution (perhaps even a good solution!). Geoserver
could add parameters for each of the Cache-Content sub-params to the
"featuretype configuration" page, and form a Cache-Content response
header appropriately for each map by dispatching on the requested
featuretype.

Has anyone butted up against this sort of results caching, and how have
they approached it? Any thoughts from the rest of the geoserver
users/developers?

I'm game to implement this, but I'd love to hear that someone else has
already solved this problem!

thanks,
--saul

Hi Saul,

I dont know of anyone butting into this exact problem, but a similar one involving changing the "strategy" used to build a response. The appropriate interface to look at is AbstractService#ServiceStrategy.

You will see there a few implementations, BufferStrategy,FileStrategy,etc... you may be able to create a new CachingStrategy to accomplish your goal.

Sorry I cant give you a more concrete answer, I would have to spend more time looking at your problem. Why dont you take a look at the classes mentioned above and see if it will work for you. If not I would be happy to continue discussions on how we can acheive the functionality you want. And we are always eager to take on volunteers so if you are game to implement, we are game to help!!

-Justin

Saul Farber wrote:

Hello all,

I've recently been poking at ka-map (http://ka-map.maptools.org/) and
got it to serve up its maps with a javascript-only browser-application
backed by the geoserver WMS.

However, it's abundantly clear that this needs caching. Putting squid
in front of geoserver can help tremendously, but squid is very reluctant
to cache anything without proper caching meta-information in the
appropriate http headers.

I learned the (very very small!) bits that I know from
http://www.mnot.net/cache_docs/

I was thinking that since adding caching headers to dynamically
generated maps is probably very bad "default" behavior, this might be
better accomplished by having some kind of "per-map" or "per-dataset"
information which would prompt geoserver to add appropriate
"Cache-Content" headers to an image or WFS response.

Oh, and this would clearly only work with WMS/WFS "KVP-GET" requests, as
caches pretty much ignore POST-ed content. And it seems to make more
sense with WMS than WFS, for that matter.

One way would be something like this:

Allow getmap requests to be specified as follows -
http://my.geoserver.instance/geoserver/wms/getmap?my=get&map=looks&like=this&cache=3600s

This would add the header:
"Cache-Content: max-age=3600s"
to the generated map.

This is slightly clunky, as there are a number of "sub-params" which can
go into Cache-Content (see that page above for details) and really only
solves one very specific form of the caching problem

A different way would be something like this:

For datasets that change infrequently, caching for a long time seems to
be a less "bad" solution (perhaps even a good solution!). Geoserver
could add parameters for each of the Cache-Content sub-params to the
"featuretype configuration" page, and form a Cache-Content response
header appropriately for each map by dispatching on the requested
featuretype.

Has anyone butted up against this sort of results caching, and how have
they approached it? Any thoughts from the rest of the geoserver
users/developers?

I'm game to implement this, but I'd love to hear that someone else has
already solved this problem!

thanks,
--saul

-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org