If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

SSL pages cached to disk when browser.cache.disk_cache_ssl is false

RESOLVED WORKSFORME

Status

()

Core
Networking: Cache
--
major
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: amesbury, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042523 Ubuntu/8.10 (intrepid) Firefox/3.0.10

With browser.cache.disk_cache_ssl set to false (default value), Firefox writes SSL pages to disk.  These are detectable in about:cache (HTTPS links show up in "Disk cache device" cache entries) and also appear in the cache on disk.

This bug may be related to #205921.

Reproducible: Always

Steps to Reproduce:
1.  Open about:cache
2.  Go to an HTTPS page (e.g., http://mail.google.com/)
3a.  Check "Disk cache device" for presence of HTTPS objects; and
 b.  Check path to disk cache for files containing content retrieved via HTTPS.
Actual Results:  
SSL content was cached on disk.

Expected Results:  
It should not cache SSL content on disk unless browser.cache.disk_cache_ssl is true.
Component: Security → Networking: Cache
Product: Firefox → Core
QA Contact: firefox → networking.cache
We also (now) cache SSL content with an explicit "Cache-Control: public" header. This is typically used by high-traffic sites (such as GMail) for common repeated but not sensitive elements like scripts and page layout images. Otherwise their servers get hammered by all the repeated requests and users may complain about bad performance of constant network fetches.

Open about:cache?device=disk and then click on the individual https:// items you see. This will show you the headers and other information. If you find any that don't have Cache-control: public then we've got a bug, otherwise this bug is WORKSFORME/INVALID.
(Reporter)

Comment 2

9 years ago
It's the cache-control stuff being set to public that's causing it with Gmail.  I'm not certain about another application about which I've heard problems, but it seems much more likely now that the problem lies there.

Thanks for the quick response!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Thanks for reporting.

If you see this again in that other web app please do check the cached headers and let us know if they're not explicitly public. We definitely want to fix any unintentional leaks.
You need to log in before you can comment on or make changes to this bug.