From @grangeway, by e-mail 5 Aug 2019 01:48:12

FYI -
I remember this from the past - the other thing with this is some users that were using proxy servers had a different behaviour.

For instance, I found that IE11 in a corporate environment would work in different ways; there were a few associated issues in the tracker back in the day - aka the Cache-Control header

If I recall, their were two main problems with the headers:

a) what happens in various file download scenario's

b) what happens on the bug report pages (in terms of losing comments)

For public sites running mantis, they'll likely be users using firefox/chrome/edge.

For corporate sites running mantis, there's a good chance they will still be on IE of some description

why the +10 days change - that looks strange?

Paul

I have noticed also a more frequent "invalid token" fail when reporting issues. Probably related too?

why the +10 days change - that looks strange?

This is an arbitrary value. Maybe we could stay safer with a lower value, eg: 1 day?
Anyway, some recommendations even say to use an abdsurdly far date in the future, like year 2999, to make sure the page is cached (as intended)

I am not an expert, but my understanding is that the previous Expire date as "now" would render the cached page obsolete as soon the browser loads it. So effectively avoiding it to be cached.
By having an expiration date in the future, joined with the cache-control headers, allows the browser to use the cached copy.

I open this PR: https://github.com/mantisbt/mantisbt/pull/1539
that removes those $g_allow_browser_cache = 1
in case you find that is the best approach.