David Scotson

That may be possible for non-logged in users but surely that approach is not efficient for logged in users, like myself, who have customised many of the available options? Maybe they cache at the database level for such users?

Either way they seem to be avoiding the original problem in this thread which means it is perhaps possible to solve it while leaving the "cache/don't cache" and "double-form-submission" problems for later.

Can someone try removing the 'no-store' header, leaving the 'no-cache' one intact, and see what difference that makes?

Can anyone then explain why slashdot which, according to Firefox's "Live HTTP Headers" extension, is using no-cache but not no-store is able to show this behaviour (returning to the clicked link on 'back')?.

Does anyone understand the interaction and differences between 'no-cache' and 'no-store'?

As far as I can tell 'no-store' is intended as a security measure to prevent people from browsing your history and seeing what you filled in to forms etc. This may, as I mentioned earlier, be the eventual cause of users losing their written entries when they try to recover from other errors by using the back button.

This seems to be different from 'no-cache' which (logically at least) should only apply when the browser is deciding whether to load the page again or re-use a cached copy and not when browsing your history.

I can understand why Moodle would want to avoid using the cache but I don't think it's as clear cut why it shouldn't store previously visited pages.

Form submission should not allow double submissions anyway. This can be controlled by what my Core J2EE Patterns book refers to as a Synchronisation (or Déjá Vu) Token.

Basically each form has a unique token in a hidden field which is checked and discarded at submission. If the same token is submitted for a second time then there is an error that can be dealt with gracefully.

In this case you could either chasten the user for doing something crazy (note that their browser will give them a scary warning about "post" data), or second-guess their intentions and take them directly to an edit view of the original post.

This clearing of form fields may help explain some of the strange intermittent error reports we have been receiving from users, where simple and expected errors (e.g. timeouts) result in dataloss because the back button won't retrieve the form contents.

These kind of questions turn up every so often and usually, as with Tim's comment above, because the requested 'features' are needed to convince a non-technical, non-teaching bureaucracy rather than for any real benefit to those teaching or learning (often these suggestions will actually harm the learning experience).

Rather than just shoot down each request individually as it comes in, would it be possible to try and collect together some of the very real on-line teaching and learning experience that is present in the community to produce 'position papers' to explain:

• what is actually possible in a technical sense
• what the pedagogic/social impact of implementing such a solution would be
• why Moodle as a community is not investing time implementing this 'feature'
• propose other approaches that would achieve the same goal

I'm not saying that every bureaucrat is susceptible to reason, but having a page to point to with a comprehensive canned answer makes you seem less negative than simply saying "no, that's a stupid idea" or "that'll never work".

So would this crazy idea work? Is collecting the threads addressing these in a wiki a good start? Does anyone have suggestions for commonly asked questions that require a polite "no"?