Our current caching efforts will focus on (details on each provided further on):
Also nice-to-have:
allow resource classes to set caching headers (+ if modified since, etc.): what support by JAX-RS and Restlet (link) ? Should solve itself with Restlet 1.2, don't perform effort? Provide example for JAX-RS?
caching (based on validation) for dbresources
Caching only relevant for GET requests.
Often the term "backend caching" is used for situations where caching is performed by the web site itself (e.g. app-specific, using memcached etc.), but not by intermediaries.
All personalized content does not (or much less) benefit from caching. Solution: no personalisation.
All pages who's content depends on the values of cookies cannot easily benefit from caching (Vary: Cookie), think of e.g. the i18n cookie.
The general idea is: cache indefinitely, change file name when contents changes.
Could also consider use of hosted libraries for common dependencies (jquery).
Cases:
without any caching headers, clients are allowed to cache. IE does this, concrete problem case: dbforms sample where jqgrid is not updated after creating new entity. Can be solved by marking it as non-cacheable (or with appropriate validation strategy), or by appending query parameter with timestamp when client does request.
normally, resources requiring authentication are not cached, unless explicitly marked as public. Problem: for cookie-based authentication, it is not known to intermediaries that these are authenticated requests. Therefore: do something on authentication system level to disable caching by default for such resources?
by default, probably developers expect resources not to be cached: should we therefore make resources non-cacheable by default in Kauri?
Cases:
