I think this is also fixed by removing the "no-store" from the Cache-Control header when serving pages in JIRA.

We need to look into this anyway.

Chat to Chris Owen about removing the "no-store" from the Cache-Control header.

Yes,, it will keep the form from becoming unpopulated. However, won't you still have the problem of it asking for permission to re-post? Or will it simply display the cached result on navigating the history back to a POST?

I haven't tried every combination of browser and Cache-Control, and don't have time to set up the experiments myself, but I do know a redirect works wonders, though at the cost of an extra round-trip.

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.

This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

Now, that "if the entity is still in storage" part would seem to give browsers a little wiggle room, but the intent is clear.

Of course, this is moot if the browsers don't implement it. I take it you've verified they do.

Always good to learn something new! (Even about something old, like HTTP/1.1 caching!)

Thanks!