View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025969||mantisbt||other||public||2019-08-05 18:41||2019-08-13 23:47|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.22.0||Fixed in Version||2.22.0|
|Summary||0025969: bug_report_page is forced to be cached|
Now bug_report_page is being cached by the browser.
The changes to http_caching_headers, that affects this scenario is that:
The report page has an explicit
I suspect that previous behavior was not actually correct, since setting the "Expires" date to "now" wasn't working as expected to allow caching.
Should we remove those
|Tags||No tags attached.|
From @grangeway, by e-mail 5 Aug 2019 01:48:12
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?
I have noticed also a more frequent "invalid token" fail when reporting issues. Probably related too?
This is an arbitrary value. Maybe we could stay safer with a lower value, eg: 1 day?
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.
I open this PR: https://github.com/mantisbt/mantisbt/pull/1539
MantisBT: master 82b8d472
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
|mod - bug_change_status_page.php||Diff File|
|mod - bug_report_page.php||Diff File|
|mod - bug_update_page.php||Diff File|
|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|