Cache in AppEngine
To correctly set the cache for Google App Engine looks like an easy task, but in order to fully understand the story behind the scene turns out to be a little bit tricky as there are some hidden points that only can be discovered from various posts that scattered in the cloud.
Some highlighted points here which I have learned from the research:
1) For static files, the cache is being set in the appengine-web.xml file, you can specify how long it is going to expire within the file.
The cache here is if you don’t declare your static file here, then quite possibly you will not be able to render your static file well. Google use a different source to serve static files, as a result you have to explicitly tells AppEngine that “these are the types of static files I am using, and you need to serve it”. An alternative is to add those static files into your web.xml as a servlet or a filter, which will then be caught by the servlet/filter chain, however, this is not the recommended way to go.
2) You can use a filter to add “cache-control” header to static files request/response, but Google will not honor it. To be precisely, Google will always return a private cache-control for your static files regardless what kind of setting you provided. Hence these static files will only available in your private cache pool (local browser), and will expire after your specified length.
3) However, we can use above mentioned method to add “cache-control” header to dynamic generated pages, such as jsp file. This is particularly useful for files that rarely change, such as front-page or some introduction pages. And this time, Google will honor your setting in your cache-control header with the right expire time.
4) The way current browser working is a little bit weird but understandable:
If you click a link on a page, then browser will always first check if there is a local cache available, if not then goes to the server to fetch.
If you press F5/Refresh the page, the the browser will just ignore your local browser cache at all, but goes directly to the server. This time, it will use the “is-modified-since” header to compare whether the content on the server side is still valid, if it is, then a 304 will return and you will still use your local cache, otherwise a new version will be retrieved.
In short, if you click the link, then it is possible that client will not talk to the server at all, but if you refresh, then the client will always talk to the server.
5) Both Chrome and Firefox have good tools for debugging HTTP Request, see how the cache is working and diagnose each of the specific request.
