bluebones.net

Adventures in Computer Programming

1. Jonny Axelsson 2007.09.18

   Opera is not ignoring these headers, if you set Cache-control to no-cache it will not be cached, and no-store it will not be stored on disk. But it is very common to confuse cache, a local copy of a resource as to avoid a server round-trip, and history (going back to the pages you have viewed before.). These are two very different concepts. If you had followed the link to the HTTP 1.1 specification, Section 13.13 you would read:

   13.13 History Lists
   User agents often have history mechanisms, such as “Back” buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

   History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

   By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

   It could hardly be clearer. Cache-directives do not apply to history.
2. Thomas David Baker 2007.09.18

   Hey Jonny,

   Sorry, my last paragraph is incorrect - it’s not ignoring them it’s just not doing what I expect. I can completely see your point. One might question whether this is desirable behaviour, though it’s certainly in the RFC.

   Apart from the “viewing is a security breach” scenario which may be a bit far-fetched, what about the situation where you are storing some state in the page. To resubmit this will result in a failure. So you want to tell Opera: “hey, once they’ve navigated off this page it’s old news - don’t show it to them again”. It seems to me that although a user might want to view pages they have visited, they are more likely to be hitting the back button to get back to “that page where I can “. In this scenario hasn’t Opera failed them as a user experience however perfect it’s implementation of the RFC?

   Happy to be wrong if you have any more comment to make! I haven’t actually used Opera for a while so this is all a bit hand-wavy from me!
3. Jonny Axelsson 2007.09.18

   As you might guess I care about the history function. It is important for usability, and if you flutter back and forth in history, as Opera and more recently Firefox 2+ encourages, you will see why.

   I also care about Opera, or for that matter other browsers and servers, complying to HTTP. HTTP is a protocol, and in my view it is more important that this works seamlessly than say a format like HTML (of course you want to do both).

   From an efficiency viewpoint it is also a pity that the cache mechanism, the most complex and powerful part of HTTP is largely disabled, partly for valid reasons like yours, but mostly for understandable but unfortunate reasons. If you have ads that pay per view (the most common case) and the ad is cached you make less money. The solution is to specify that just the ad shouldn’t be cached, but this is often hard(er) to do than prevent the entire page from being cached.

   But your question is a valid one. HTTP is designed to be (mostly) stateless. This is by design (look up “REST” if you want the ideology), but that doesn’t mean that there aren’t applications that have state, and need to keep that state over multiple pages.

   First of all if the cache control is a security concern with your application, you are already in trouble. Any HTTP request can be crafted by hand/tool, you don’t need a browser. On the server side you simply cannot assume that people will follow the path you have imagined they will.

   A robust application will recover from any state to “just work”, effectively serving the appropriate response (better than “shame on you”), whether the state is stored in a cookie, the URL, ET tags or other mechanisms. (For the banks part of the answer is that the important things they do will be in an HTTPS session, again a case of state). This can happen with any browser, e.g if it has been offline for some time and then continue. People who use laptops or phones on the move will recognize that situation.

   (This happened to me right now in fact, my wireless connection dropped without me noticing. If I couldn’t have gone back in history when I got the error message, I would have had to retype this response.)
4. Thomas David Baker 2007.09.19

   These are interesting points that you raise. I can see that it is very useful to have a complete history of your browsing. “Oh hang on what was the name of that thing?” - search history - find it. And I can see that browsers are only going to have more features like this.

   Let me pick your brains. What would you do for a page with state? Say, for example, that you have an AJAX-y page where you can edit a page layout with drag and drop of various graphical elements. You don’t want to allow someone to return to the page at an arbitrary point in the past, you want them always to see what is currently saved on the server when they start editing. (I’m leaving aside server-side prevention of saving, it’s the user experience I’m talking about here.)

   With Firefox using the back button after saving takes you back to the *original* state of the page. Not the state just before it was saved. But you can ask Firefox not to cache and it is quite good about it.

   Perhaps Opera takes you back to the page as it was just before you clicked Save?
5. jans 2008.09.06

   Visit http://developmentzone.blogspot.com/2008/09/prevent-browser-from-caching-webpage.html for more details.

Entries RSS Comments RSS