Yeah, the SimpleCachingHeadersPageCachingFilter I use both caches server
side (memory first, then disk) as well as setting cache headers - so if
that's the definition of "client side caching" then of course I am all
for it. However this is a distributed world, one clients cache knowledge
won't make much of a difference considering the remaining 9999 clients.
I like to think of this a little bit like the "eventually consistent"
moniker; it's can be ok for practical purposes to not show the most
current view of a resource for the bennifits of the overall performance
for all 10000 clients. Of course this is all context specific.
Thanks for the Mark Nottingham pointer [
http://www.mnot.net/cache_docs/].
/Casper
> Again, it depends on the application, and caching can happen on web
> proxies, can happen on servers, can happen on clients.
>
> Casper, from what you describe i think you are generally doing the
> right approach but may want to review (if not already) the use of the
> Cache-Control header to ensure proxies and clients handle the
> representations properly.
>
> The Cache-Control header can define how web-proxies and clients can
> cache resources according to HTTP caching semantics. But a word of
> warning the cacheing semantics of HTTP are probably the most difficult
> aspect of HTTP to understand, which is why using a caching proxy
> server close to the edge/clients might be a good approach.
>
> Mark Nottingham has written some excellent documents on HTTP caching.
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>