Felix Meschberger wrote > Hi all, > > I have been resonating with a collegue about a request level Filter > for Sling to support caching. > > The idea (and partly implemented by a prototype) is to have the > request filter setup default caching behaviour of the response (if the > response is cacheable at, that is the request method must be GET and > there are no request parameters): > > * The Cache-Control header is preset with values from configuration > matching the request URI (or resource path) > * The Last-Modified header is preset with the jcr:lastModified > property of the requet's resource > * Eager responding with 304/NOT MODIFIED if the If-Modified-Since > header is set and a last modification time of the resource can be > resolved. > > ll these settings can be overwritten/replaced by the request > processing scripts but it at least sets some defaults for caching: > > * Caching of the response enabled at all > * Whether revalidation by clients and/or proxies is required > * etc... > > Configuration could be something like: > * Enable/Disable caching support functionality completely > * List of URL (or resource path) regexps with their setup, e.g. > ^/(apps|libs)\/.*=must-revalidate > * Enabled/Disable support for eager 304 responses > > This would probably just be a first step in a new infrastructure > around supporting response caching. > Sounds cool to me, especially the ootb if-modified-since support (we have the same in Cocoon and it works pretty well).
The only question I have, why a filter? :) I know this can be added transparently, but do we need that? I'm not against this, just curious - especially as I hate debugging a large filter chain :) Regards Carsten -- Carsten Ziegeler [email protected]
