View Issue Details

IDProjectCategoryView StatusLast Update
0025969mantisbtotherpublic2024-01-07 12:30
Reportercproensa Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version2.22.0Fixed in Version2.22.0 
Summary0025969: bug_report_page is forced to be cached

After MantisBT master 97b745dc

Now bug_report_page is being cached by the browser.
The wrong behavior i see is:
Once in the report page, i change the active project to report in a different project.

  • before: the page was reloaded with the new project fields
  • after: the page does not change, as is loaded from browser cache.

The changes to http_caching_headers, that affects this scenario is that:

  • before: header "Expires" sets date to "now"
  • after: header "Expires" sets date to "now"+10 days

The report page has an explicit $g_allow_browser_cache = 1;
that means that it's overriding the default caching behavior (by default it's to not allow caching)
originated in this 2014 commit: MantisBT master d508493a

I suspect that previous behavior was not actually correct, since setting the "Expires" date to "now" wasn't working as expected to allow caching.
And force the caching of the page is not a good solution to the problem (0016570), especially now that modern browsers already loads a cached page after using the "back" functionality.

Should we remove those $g_allow_browser_cache = 1; ?

EDIT [dregad] replace github URLs with internal, source-integration references

TagsNo tags attached.


related to 0024189 closedcproensa Status color squares become black 
related to 0016570 closedgrangeway Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser 
related to 0026477 acknowledged Removing the caching of pages with validation gives returns the "empty form on back" bug 0003728 
related to 0013286 closeddregad Cannot change g_allow_browser_cache for plugin.php 
related to 0033482 resolveddregad Use config API to access allow_browser_cache 




2019-08-06 06:01

developer   ~0062518

Last edited: 2019-08-06 06:02

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

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?




2019-08-06 15:01

developer   ~0062523

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.



2019-08-06 17:36

developer   ~0062524

I open this PR:
that removes those $g_allow_browser_cache = 1
in case you find that is the best approach.

Related Changesets

MantisBT: master 82b8d472

2019-08-06 12:30


Committer: vboctor

Details Diff
Don't force caching of form pages

These pages were explicitly setting a flag to make the pages cacheable.
Before the changes in 97b745dc102323c312ca27b6fcb8f838c3e50b8f
the expiration headers were not being correctly set, however after that
commit, the issue is fixed and these pages have become cacheable
This causes undesired effects.

Since the previos status of this scenario is that the pages were not
being cached anyway, we are removing the explicit $g_allow_browser_cache

Fixes: 0025969
Affected Issues
mod - bug_change_status_page.php Diff File
mod - bug_report_page.php Diff File
mod - bug_update_page.php Diff File