caching, no-cache, and Etags in TiddlyWeb

[jnthnlstr]

Hello,

I had a discussion on #pubstandards IRC today about how to stop the
browser from caching my pages after a person had logged-in to a site.
There is also the need to not display the logged-in versions of pages
after the person has logged out.

I was suggested two routes:
- use "Pragma: no-cache" on all logged-in pages to make sure the
browser never caches them
- use "Vary: Cookie" on pages with specific (but not sensitive)
differences between logged-in and not logged-in state

Later, I searched on the TiddlyWeb group for "no-cache" and found this
thread [1] where Chris Dent is admonishing Simon for using "no-cache",
recommending the use of valid Etags instead.

I would like to not break the web. However, I would also like to make
sure people see what they are supposed to see when they log in and
out. At the moment, my site has a lot of usage of start_response(...),
so I am in a position to tweak headers if necessary; however, this
also means I'm not sending Etags along.

Has anyone else resolved this problem?

Thanks,


J.

[1]
http://groups.google.com/group/tiddlyweb/browse_thread/thread/e3e26870cb6e9950/0a59ca23d3a4b275?lnk=gst&q=cache+control#0a59ca23d3a4b275

[Paul Downey]

> to make sure the browser never caches them

The question I think you want to ask is "how do I make my pages more
cachable and yet refreshed when the resource has changed":

http://www.mnot.net/cache_docs/

--
Paul (psd)
http://blog.whatfettle.com

[Chris Dent]

On Nov 26, 2009, at 4:21 PM, jnthnlstr wrote:

> I had a discussion on #pubstandards IRC today about how to stop the
> browser from caching my pages after a person had logged-in to a site.
> There is also the need to not display the logged-in versions of pages
> after the person has logged out.

> I was suggested two routes:
> - use "Pragma: no-cache" on all logged-in pages to make sure the
> browser never caches them

This would be a bummer, as it means logged in users don't get to benefit from caching, would in some cases will slow things down quite a bit.

In any case, when we talk about how caching is handled in TiddlyWeb, we need to be sure we are talking about which urls or which code is being invoked, because the handling is different in different places.

When GETting a single tiddler or a list of tiddlers the response includes an ETag, and a Cache-Control setting of 'no-cache'. Contrary to what it might seem like 'no-cache' might mean there, what it really means is "when thinking of using the cached representation of this resource, first query the server to validate that the version you've got is fresh". The browsers sends a conditional GET to the server, the server responds with a 304 if what's in the browser is okay, 200 and the new content if it is not.

"no-cache" is used because we do not want the browser to be out of sync with the server and the resources on the server are being changed by multiple sessions.

> - use "Vary: Cookie" on pages with specific (but not sensitive)
> differences between logged-in and not logged-in state

This won't have quite the desired effect for tiddler resources, because of that no-cache setting on Cache-Control: Vary only comes into play when locally validating the cache local to the browser (or the caching proxy server). Because no-cache is set, the browser will always validate upstream, whatever the Vary header says.

This means the browser always sends an If-None-Match Conditional GET request with the ETag up to the server. As currently written that ETag is the same whoever the current user is. Despite my equivocation in the thread you quoted[1], I now reckon, given the no-cache setting, that this has to be considered a bug and will need to be fixed in a way that is similar to how issues with mime-types and ETags were handled[2].

> I would like to not break the web. However, I would also like to make
> sure people see what they are supposed to see when they log in and
> out. At the moment, my site has a lot of usage of start_response(...),
> so I am in a position to tweak headers if necessary; however, this
> also means I'm not sending Etags along.

For the tiddler(s) resources my fix described above will fix things (I believe (when I get it done (which should be soon))). For other URLs, ones for which you have control of the start_response, if you want to ensure that caching is handled well in the face of logging in and out, you've got a few options:

* send a Vary: Cookie header
* send a Cache-Control: no-store

Both of these assume that you are not setting ETags or Last-Modified headers and that the content you are sending is dynamic generated.

[1] http://groups.google.com/group/tiddlyweb/browse_thread/thread/2bda56817b0866a9/d37d0c8130dee894

[2] http://github.com/tiddlyweb/tiddlyweb/commit/2ec9a4604222004de5b84e3f0e9f4eaba47bc2bb
FND, since I can generally rely on you at this point to be concerned about the ServerSideAdaptor and TiddlyWebAdaptor's handling of ETags at this point, the situation remains the same as it did when we made the first change: The server will still only validate the first part of the ETag on tiddler PUT.