User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Steps to reproduce: 1. Go to https://test.shhnjk.com/embedder.php?url=data:text/html,%3Ciframe%20src=http://shhnjk.com/%3E 2. Perform super reload (Ctrl+F5 on Windows) Actual results: Resource inside data URL is still served from cache Expected results: Firefox permanently caches resource loaded inside data URL. Even after performing super reload. Combined with https://bugzilla.mozilla.org/show_bug.cgi?id=1393880, MITM attacker can place modified content permanently, even after victim leaves MITM network.
Christoph, do you know what is happening here?
(In reply to Andrew Overholt [:overholt] from comment #1) > Christoph, do you know what is happening here? Andrew, this seems more like a caching issue to me. I discussed things with Dan on IRC and it doesn't seem too critical, but I think we need to pump this one over to some other component, maybe Necko? Probably we need to transfer some flag 'force reload' even if the cache would think it's still fresh enough to load from cache.
Honza, can you take a look?
Also asking Michal to have a look in case Honza is still swamped. This is P1 (for now at least) so high priority. A bisect would be interesting--if this has been happening forever, I doubt it will stay at P1.
This is not a regression. This test can reproduce the problem since changeset cd36476dd8b3, earlier revisions fail to load the iframe due to embedded data in src attribute. If I move the embedded data into a separate html page, then I can reproduce it from revision bc2fc3ae3bd2. Earlier revisions cannot handle embedded data as a document and try to find a plugin for the data. The resource is read from the cache because it is in a different load group. I guess this must be fixed somewhere in the DOM.