1747019 - Cache problem on cgi pages

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Alain Boute]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

• load a HTML form via https
• submit the form with POST -> the returned page also contains a form
• submit the returned form with POST
• return to previous page with the Back button

Actual results:

The cache is not used : form is submitted again to get a fresh response
The submit confirmation is not displayed
The bug is intermittent : sometimes the cache is used

Expected results:

Cache should be used : header contains Cache-Control: private; Max-age=604800
This happened first on Dec 2 2021
Tried various Cache-Control headers : no way

May be the same reason as Bug 1745851

Comment 1

[Alain Boute]

This happened first with Firefox 95

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cache' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Dragana Damjanovic [:dragana]]

Do you have a test that we can use?

Comment 4

[Alain Boute]

Test site :
https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

Comment 5

[Kershaw Chang [:kershaw]]

(In reply to boute from comment #4)

Test site :
https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

Sorry, I have no idea about how to reproduce the problem with this site.
Could you provide some detailed steps?
Thanks.

Comment 6

[Alain Boute]

To reproduce the bug :

• login with the given credentials
• click on the link [Liste des usagers]
• use the firefox [Back] left arrow to redisplay the previous page

The cache is not used : form is submitted again to get a fresh response (see date/time displayed on top/right of the page)
The submit confirmation is not displayed

Notes :

• when you use the firefox [Forward] right arrow, the cache is used as expected

Comment 7

[Alain Boute]

• at this point, both firefox letf and right arrows work as expected between those 2 pages
• most of the time, clicking on a new link and using the firefox left arrow causes the bug again, but sometimes not

Comment 8

[Kershaw Chang [:kershaw]]

I just found that the cache-control header in the response from https://evasoft.fr/eva/demo-social.cgi seems not right.

[Cache-Control: private; Max-age=604800]

According to spec, this should be private, max-age=604800.
Could you fix it and see if Firefox can work as excepted?

Comment 9

[Alain Boute]

Thank you for the correction
I corrected the Cache-Control header and it works as expected
However, the bug is still present if no Cache-Control header is present
You may check this at address https://ux1.evasoft.fr/eva/demo-social.cgi

The most serious part of the bug is : The re-submit confirmation is not displayed
This is harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)
It's unconvenient when the page returned requires heavy computation

We have many sites suffering from this change since firefox 95
We have thousands of users and many of theim switched to Chrome because of this new behaviour

I dont know if the reason is the same, but I cannot login to https://www.ovh.com/auth/ since firefox 95

Comment 10

[Kershaw Chang [:kershaw]]

(In reply to Alain Boute from comment #9)

Thank you for the correction
I corrected the Cache-Control header and it works as expected
However, the bug is still present if no Cache-Control header is present
You may check this at address https://ux1.evasoft.fr/eva/demo-social.cgi

This seems like can be fixed by adding Cache-Control header?

The most serious part of the bug is : The re-submit confirmation is not displayed
This is harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)
It's unconvenient when the page returned requires heavy computation

We have many sites suffering from this change since firefox 95
We have thousands of users and many of theim switched to Chrome because of this new behaviour

I dont know if the reason is the same, but I cannot login to https://www.ovh.com/auth/ since firefox 95

Is this a different issue?
If yes, Could you help us by using mozregregression to find out the root cause?
Thanks.

Comment 11

[Alain Boute]

It worked without Cache-Control header before firefox 95
I will check with mozregregression to find out the origin

Comment 12

[Alain Boute]

Checked with mozregregression : if found one bug report
Bug 1746223 Move ScreenOrientation.lock to version 97 in changelog r=geckoview-reviewers,agi DONTBUILD

Comment 13

[Kershaw Chang [:kershaw]]

(In reply to Alain Boute from comment #12)

Checked with mozregregression : if found one bug report
Bug 1746223 Move ScreenOrientation.lock to version 97 in changelog r=geckoview-reviewers,agi DONTBUILD

It's unlikely that bug 1746223 caused this problem.
Could you check again? Thanks.

Comment 14

[Alain Boute]

The Cache-Control header does not correct the bug but it appears less often
To reproduce the bug with Cache-Control header, use the test site https://evasoft.fr/eva/demo-social.cgi
User : firefox
Password : test

• login with the given credentials
• click on the link [Liste des usagers]
• click on the link [TEST Alain]
• use the firefox [Back] left arrow to redisplay the previous page (once or twice)

The cache is not used : form is submitted again to get a fresh response (see date/time displayed on top/right of the page)
The re-submit confirmation is not displayed

This bug is intermittent : mozregregression may not give a pertinent diagnosis

Comment 15

[Alain Boute]

About Severity = S3

I suggest Severity = S2 because :

• no workaround is known (The Cache-Control header does not correct the bug)
• it's harmfull when the submited POST has a permanent action (new record in a database, send an email, ...)

Many sites are suffering from this change since firefox 95
Thousands of our users and switched to Chrome because of this new behaviour

Comment 16

[Kershaw Chang [:kershaw]]

Valentin, do you probably have an idea which recent change that could cause this?
Thanks.

Comment 17

[Valentin Gosu [:valentin] (he/him)]

I did a mozregression myself and it points to bug 1732358.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1732358

Comment 19

[Ryan VanderMeulen [:RyanVM]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #17)

I did a mozregression myself and it points to bug 1732358.

Can you try running mozregression with the fission pref set to find a better range?

Comment 20

[Valentin Gosu [:valentin] (he/him)]

Running ./mach mozregression --pref "fission.autostart:true" -g 80 came up with the following range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c25899d7b631470b983650ee254177381a62eaad&tochange=33139800aca52aac192973fe24c9b74df7c87e00

It could be bug 1668357 but I haven't confirmed yet.

Comment 21

[Valentin Gosu [:valentin] (he/him)]

I've confirmed this is caused by https://hg.mozilla.org/integration/autoland/rev/1aa67f749387
Olli, can you take a look?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

So with Fission the previous page doesn't enter bfcache.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

...but even without bfcache we have an issue with cache key.
Of course in general one can't assume the cache contains any entries.

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Bug 1747019 - set cache key on session history entry, r=peterv

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/82197520e6a1
set cache key on session history entry, r=peterv

Comment 26

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/82197520e6a1