When doing web development, i often use a chrome extension called "Classic Cache Killer". This helps to make sure that Chrome reloads everything every time you load a page.

As for browser history: At least in Chrome, it saves a nearly complete copy of the page "as seen" in RAM most of the time. But not all the time. It has some kind of smarts that not always do what you expect. Sometimes it reloads some resources, sometimes it doesn't. From what i understand, the behaviour depends which javascripts are active but also on the headers of the loaded resources and *how* those resources have been loaded. It could also depend on how you left the page you are trying to go back in history.

For example, the "Vary" header can make a response uncachable. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary

Leaving a page by POSTing a form can also make a page uncachable (or rather "wrong to go back to in history"). This is because POST is assumed to change data on the server, and when you GET a resource, then POST to it, the browser may or may not assume that the history of the previous "GET" request is invalid and try to reload some or all of the resources.

Basically, going back in time can violate the Idempotency of a chain of requests and that can lead to all sorts of weird and wonderful results. And that may include accidentally ordering the same Amazon shopping cart twice or posting the same reply on Perlmonks a dozen times.

Idempotent methods in HTTP are GET, HEAD, PUT, DELETE, OPTIONS and TRACE. Although for the browser history to be usable, i guess the methods used in the chain also need to be Safe (GET, HEAD, OPTIONS) and all results cachable.

So technically, as soon as you use PUT, DELETE, POST, CONNECT or PATCH, everything before that call becomes invalid. If you go back in time to a page before such a call, it is not a usable page in the sense that you can submit a webform and expect it to work correctly.

As for your case of duplicates appearing, this could simply be a case where you submit a post, then go back in time before submitting the post (not "editing an existing post") and resubmit it again. Meaning the webform still has the "this is a new reply" flag set (or missing the "editing node 12345678" field, whatever).

> . From what i understand, the behaviour depends which javascripts are active but also on the headers of the loaded resources and how those resources have been loaded.

That's a good point, I have some Nodelet Hacks active, one even registering an onSubmit handler.

So this might be a private problem. Will try to run some tests after the German Perl Workshop...

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}