view-source: uses the cached version of a page, not respecting the caching headers from GMail or other sites
Categories
(Core :: Networking, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
platform-rel | --- | - |
People
(Reporter: sebg.1969, Unassigned)
References
Details
(Keywords: sec-low, Whiteboard: [necko-triaged][platform-rel-Google][platform-rel-Gmail][necko-priority-next])
Attachments
(1 file, 1 obsolete file)
Comment 1•8 years ago
|
||
Comment 2•8 years ago
|
||
Comment 6•8 years ago
|
||
Comment 7•8 years ago
|
||
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
Comment 8•8 years ago
|
||
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
Comment 11•8 years ago
|
||
Comment 13•8 years ago
|
||
Updated•8 years ago
|
Comment 16•8 years ago
|
||
Comment 17•8 years ago
|
||
Updated•8 years ago
|
Comment 18•8 years ago
|
||
Comment 19•8 years ago
|
||
Comment 20•8 years ago
|
||
Comment 22•7 years ago
|
||
Updated•7 years ago
|
Comment 23•7 years ago
|
||
Comment 24•7 years ago
|
||
Comment 25•7 years ago
|
||
Comment 26•7 years ago
|
||
Comment 27•6 years ago
|
||
Comment 28•6 years ago
|
||
Updated•6 years ago
|
Updated•4 years ago
|
Comment 30•4 years ago
|
||
This is my first contribution with bugzilla, so this may be inappropriate or the wrong place to submit but I think my experience is related to this ticket.
I'm recently switched from chrome to firefox 84.0.2 (64-Bit) Windows version as my local development/daytoday browser.
I encountered an issue while dealing with locahost form submissions. My form is being cached (filled out) until I explicitly press "SHIFT+STRG+R". Even with the appropriate no-cache headers. (Cache-Control: max-age=0, private, must-revalidate)
I measured this over 15 minutes now and a normal "refresh" wont purge my form. This leads to several backend issues and I can imagine that there is a lot of bug-potential when firefox just caching forms, that may be dynamic, or just "stale". How many forms out there are not being processed with this behavior?
I discovered while evaluating form submission during development, and it took me about 20 minutes to realize my code is just fine, but the form which is being submitted is stale... (i shouted at rails first, sorry buddy...). Whats also interesting, that even with a errored form submission (500) firefox just happily caches the form, when pressing the back button.
Coming from chrome, where a "STRG+R" purges your form, makes it hard for me arguing that this is not a bug. If so, please let me know.
Comment 31•4 years ago
|
||
(In reply to Niklas.Hanft from comment #30)
This is my first contribution with bugzilla, so this may be inappropriate or the wrong place to submit but I think my experience is related to this ticket.
I'm recently switched from chrome to firefox 84.0.2 (64-Bit) Windows version as my local development/daytoday browser.
Thank you for switching.
I encountered an issue while dealing with locahost form submissions. My form is being cached (filled out) until I explicitly press "SHIFT+STRG+R". Even with the appropriate no-cache headers. (Cache-Control: max-age=0, private, must-revalidate)
This bug report on which you're commenting is specifically related to "view source" functionality, and the issue you're reporting does not appear to be about that (even if both are related to caching - caching is a pretty broad subject!). Can you file a new bug, please? You can either flag me for needinfo on the new bug or comment here with the new bug number when you've filed it and I can make sure it is looked at.
Comment 32•4 years ago
|
||
(In reply to :Gijs (he/him) from comment #31)
(In reply to Niklas.Hanft from comment #30)
This is my first contribution with bugzilla, so this may be inappropriate or the wrong place to submit but I think my experience is related to this ticket.
I'm recently switched from chrome to firefox 84.0.2 (64-Bit) Windows version as my local development/daytoday browser.
Thank you for switching.
I encountered an issue while dealing with locahost form submissions. My form is being cached (filled out) until I explicitly press "SHIFT+STRG+R". Even with the appropriate no-cache headers. (Cache-Control: max-age=0, private, must-revalidate)
This bug report on which you're commenting is specifically related to "view source" functionality, and the issue you're reporting does not appear to be about that (even if both are related to caching - caching is a pretty broad subject!). Can you file a new bug, please? You can either flag me for needinfo on the new bug or comment here with the new bug number when you've filed it and I can make sure it is looked at.
Sorry, I must overread that! I opened a new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1688183
Comment 33•4 years ago
|
||
I just found this comments looking for the bug I just discovered : YES ! "view-source" have cache problems ! And is VERY annoying, because I'm trying to depurate my own webpage and Firefox is NOT refreshing the source code
I change one of the HTMLs I'm programming and Firefox can see the webpage changes, no problem, just "F5" refresh the webpage perfectly, but, if I hit "CTRL-U" to see the source code, Always show the same obsolete old code ! The only way to fix that is to clean Firefox cache every time I change the code
So, I'm testing my code in Chrome, no problem showing the source code updated when I hit "CTRL-U", but also works in Opera, not tested in MS browser, I don't like it too much, but I suppose will work OK
A few hours lost because of this bug ! But I love Firefox, I hope is fixed soon :D
Cheers !
Comment 34•4 years ago
|
||
I can confirm there is a bug of showing old cached page when using "view-source" function.
Looks like a serious regression.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0
Comment 35•4 years ago
|
||
View source showing cached page still not fixed in Firefox 88. Please fix, not exactly developer friendly with this bug.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Comment 36•3 years ago
|
||
I'm using Firefox 88 on Linux Mint and view source is showing cached info.
Serious problem.
Comment 37•3 years ago
|
||
On FF 88.0.1 / Linux mint this still happens, very annoying, my view source is going back to the cached login page from a previous redirect, even though I'm logged in to a site I'm testing, which difficults testing.
Comment 38•3 years ago
|
||
I'm on FF Developer 90.0b12 / Windows 7, and this is still a problem. Is there any timetable or something about when this could be fixed?
It not only is very annoying, but very problematic.
A couple of examples:
I teach web development.
When evaluating exams, one point is validating HTML to see if there's any issues. When multiple students use the sames URLs (for instance, using the same base server http://localhost:8000), like /login or /productos, if I don't remember to every single time to refresh the 'source code', then I will not be validating the correct HTML, which depending which was initially, could mistakingly mark some errores, or mistakingly show no errors.
Another case which has arisen, is when teaching HTML/php beginners a login form. When trying to login with wrong credentials, sometimes the student repopulates no only the email/user, but also the password, which is a BIG issue. One way to easily show them why it's dangerous, it's show them in the 'source code' that the password is there plainly to see. However, with this bug that is not possible.
The first time I enter the login form (and FF caches the page's source code) the form is empty. Then when I insert wrong credentials and get redirected again to the form, the values in the page will be repopulated in the form. But when I view the source code, it will show me again the original source, with the form empty. In that scenario, I can't even refresh the source code cache, because will again load the form empty.
Usually I have to show them with the Devtools or something similar, but for people very new, that can be confusing.
And also, many new students have suffered lots of time lost because this over-aggressive cache strategy. Caching local assets in localhost by default is already pretty aggressive imo. But caching the source code also is too much. I can't see how that could ever be useful.
I think it's very important to fix this, at the very least for FF Developer. For experienced users, it's extremely annoying. And for beginners, it's very confusing, error-prone and frustrating. I can attest to that from teaching.
I hope we can get some input from the dev team on this, it would be greatly appreacited.
Best regards!
Comment 40•3 years ago
|
||
@gallino.santi The workaround for web development is currently to remember to always reload the source-view: tab (!, page tab is not enough) after opening it with Firefox.
A common pattern is (FF 89.0.2):
- load a page
- change code
- reload page (CTRL+F5)
- check source code (CTRL+U)
Expected:
- see changed code
Actual:
- see source code from first page load
This has lead to much frustration here, too.
Comment 41•3 years ago
|
||
(In reply to flightvision from comment #40)
@gallino.santi The workaround for web development is currently to remember to always reload the source-view: tab (!, page tab is not enough) after opening it with Firefox.
A common pattern is (FF 89.0.2):
- load a page
- change code
- reload page (CTRL+F5)
- check source code (CTRL+U)
Expected:
- see changed code
Actual:
- see source code from first page load
This has lead to much frustration here, too.
Reload doesn't work if the cached page is a redirect to another page, like a redirect to the login page, you will be reloading the login page in the view-source. The problem is the caching when developing.
Comment 42•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 44•2 years ago
|
||
Given the slew of more recent comments here (vs. it being filed 6 years ago), as well as dupes, I wonder if something else has changed? In bug 1806223, the headers have no-cache
and Pragma: no-cache
but not no-store
or max-age=0
, AFAICT - but I'm not a cache expert so not sure if that's relevant - I don't know if we're still seeing the same thing or if this problem is now more wide-spread (comment #34 claims a regression but it's not clear on what basis). I also don't understand how refreshing the original page and then using view-source would end up showing the old version of the page - which again is different from what was reported in comment 0, as the logout would not have been on the same URL - I'd have expected the cache to have been replaced with the cache of the new page. Valentin or Kershaw, can you take another look? (Can't seem to needinfo Valentin atm...)
Comment 45•2 years ago
|
||
This is getting worse. Now view-source if used after submit resubmits form on the page without confirmation. I don't think this shoud happen given the possible implications.
Chromium based browsers reload the page on view-source, but they confirm form resubmission.
I think reloading the page on view-source is wrong. If page is reloaded from the server on view-source, it won't show the source of the page on view, but a newly loaded copy.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Comment 46•2 years ago
|
||
(In reply to Esa Ristilä from comment #45)
This is getting worse. Now view-source if used after submit resubmits form on the page without confirmation.
This is bug 1721580.
Comment 47•10 months ago
|
||
(In reply to :Gijs (he/him) from comment #44)
Given the slew of more recent comments here (vs. it being filed 6 years ago), as well as dupes, I wonder if something else has changed? In bug 1806223, the headers have
no-cache
andPragma: no-cache
but notno-store
ormax-age=0
, AFAICT - but I'm not a cache expert so not sure if that's relevant - I don't know if we're still seeing the same thing or if this problem is now more wide-spread (comment #34 claims a regression but it's not clear on what basis). I also don't understand how refreshing the original page and then using view-source would end up showing the old version of the page - which again is different from what was reported in comment 0, as the logout would not have been on the same URL - I'd have expected the cache to have been replaced with the cache of the new page. Valentin or Kershaw, can you take another look? (Can't seem to needinfo Valentin atm...)
Sorry for not having time looking at this bug. I'll bring this bug to our team's triage meeting and see what's the next step.
Comment 48•10 months ago
|
||
So I'm thinking we can probably change nsHttpChannel so that even if the channel has LOAD_FROM_CACHE, it the cache entry has no-cache and the request is for view-source, we always go to the network.
Updated•7 months ago
|
Description
•