Hi Rob, > trunk sends the deprecation INFO message when setting > Cache-control via the addAdditionalHeaders hack.
The message indicates that the manual usage of this header is discourage (not deprecated). > The Cache-control header setting is important for trying to > interoperate with certain browsers. Absolutely. > I searched but did not find any traffic on the planned means > for supporting it. We have a pending RFE to add full caching support: http://restlet.tigris.org/issues/show_bug.cgi?id=25 > I'd love to try to contribute bits to > land this one item in 1.1 if somebody can point me to the > right guidance on how Restlet should support it. That would be a great addition to the project. I can provide you design/impl support. > I have always treated this as an explicit setting made by code, > never intuited by other behavior, so a simple > setCacheControl(Message.CACHE_CONTROL_NO_CACHE) or something > like that would do for my purposes ... but happy to run down > the road of something more elegant if someone's already thunk it up. Looking at the specs: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 The idea would be to map the *semantics* of those headers into a dedicated "cacheControl" property attached to the Message class. This property would be an instance (possibly null) of a "CacheControl" class. Instead of passing a raw list of caching directive, it would provide a higher-level API, easier to understand and less fragile. Here is a proposition for a list of properties for this CacheControl class: 1) "cacheable" : Enum (CACHEABLE_NO, CACHEABLE_PUBLIC, CACHEABLE_PRIVATE) See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 2) "storable" : boolean (true by default) See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2 3) "sharedMaximumAge" : Date "maximumAge" : Date "minimumFreshness" : Long "maximumStaleness" : Long See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3 4) "returnOnlyIfCached" : boolean (false by default) "cacheMustRevalidate" : boolean (false by default) "proxyMustRevalidate" : boolean (false by default) See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 5) "transformable" : boolean (true by default) See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5 * Maybe we should also consider the support of cache extensions, maybe later only. * We should also clearly indicate in the Javadocs which properties are supported by: - responses only - requests only - both * We should also support the mapping from the older "Pragma: no-cache" HTTP 1.0 header to those properties when parsing HTTP requests. Best regards, Jerome
