Hi Sergio,
> I'm thinking in a Filter that put page results in memcache when first
> accessed, and then getting that result in former accesses.
That should work. All page cache implementations do more or less the
same.
> The idea is simple but the implementation is not. (how to get the
> first r
Thanks for your answers!
The Cache-control idea is a good one, I think I'll try something here.
But maybe it's a good idea to have some kind of server cache too.
Ehcache Web Module has a nice Java Filter that threats many corner
cases (headers, gzip, ...). The only problem is that it's too couple
I would suggest a controllable/Configurable ETag than Cache-Control,
would you not Ikai?
-Sarath
http://blog.sarathonline.com
On May 5, 5:21 pm, "Ikai L (Google)" wrote:
> Sounds like a great idea. I agree with you. The problem with setting a cache
> header is that you have very little control o
They behave differently:
* Cache-control (or Expires): if the resource has not expired, the
browser will not ask for it again (unless the user hits F5 or shift
+F5)
* ETag (or Last-Modified): the browser will ask for the resource every
time, but the server can return a 304 (not modified).
You can
Sounds like a great idea. I agree with you. The problem with setting a cache
header is that you have very little control over expiration. The nice thing
about a cache that you handle at the filter level and in Memcache is that if
you can regenerate the keys, you can flush the thing (or you can flus
In general web development, etags are discouraged because they don't work in
multiserver clusters well. They work in our deployment well for static
assets. We return the same etag for all assets for a given deployment. If
you update your deployment, even if the file has not changed, we will update
