View Issue Details

IDProjectCategoryView StatusLast Update
0025969mantisbtotherpublic2019-08-13 23:47
Reportercproensa Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version 
Target Version2.22.0Fixed in Version2.22.0 
Summary0025969: bug_report_page is forced to be cached
Description

After
https://github.com/mantisbt/mantisbt/commit/97b745dc102323c312ca27b6fcb8f838c3e50b8f

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: https://github.com/mantisbt/mantisbt/commit/d508493ab34190b7647b8b644548a565c0fc664e

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; ?

TagsNo tags attached.

Activities

dregad

dregad

2019-08-06 06:01

developer   ~0062518

Last edited: 2019-08-06 06:02

View 2 revisions

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

cproensa

cproensa

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.

cproensa

cproensa

2019-08-06 17:36

developer   ~0062524

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.

Related Changesets

MantisBT: master 82b8d472

2019-08-06 16:30:03

cproensa


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
flag.

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

Issue History

Date Modified Username Field Change
2019-08-05 18:41 cproensa New Issue
2019-08-06 06:01 dregad Note Added: 0062518
2019-08-06 06:02 dregad Note Edited: 0062518 View Revisions
2019-08-06 15:01 cproensa Note Added: 0062523
2019-08-06 17:36 cproensa Note Added: 0062524
2019-08-13 00:09 vboctor Changeset attached => MantisBT master 82b8d472
2019-08-13 00:09 cproensa Assigned To => cproensa
2019-08-13 00:09 cproensa Status new => resolved
2019-08-13 00:09 cproensa Resolution open => fixed
2019-08-13 00:09 cproensa Fixed in Version => 2.22.0
2019-08-13 16:03 atrol Target Version => 2.22.0