Closed Bug 474100 Opened 17 years ago Closed 15 years ago

FF 3.0.5 not honoring must-revalidate Cache-Control header for javascripts over HTTPS

Categories

(Firefox :: General, defect)

3.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bitpoet, Unassigned)

Details

(Whiteboard: [CLOSEME 2010-11-01])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 When a https page includes a js file that comes with a "Cache-Control: public, must-revalidate" header, on subsequent requests for the page the js is fetched from the cache without sending a request to check validity. In my understanding, the browser should send a request with "If-Modified-Since" to verify the file. Reproducible: Always Steps to Reproduce: 1. Create a html page that includes a js file 2. Create the js file and see that it is served with a "Cache-Control: max-age=xxx, public, must-revalidate" header, where xxx is a reasonably big value 3. Surf to the page via https 4. Go to a different site 5. Go back to the page via clicking on a link (clicking 'refresh' or hitting F5 forces a reload with the correct If-Modified-Since) Actual Results: No request for the js file is made, the HTTPFox plugin also shows a direct cache hit. Expected Results: FF should send a request with If-Modified-Since header, which should result in the server answering with a 304 Not Modified response. browser.cache.check_doc_frequency is set to 3, which - I believe - should be the default and correct setting. The problem arises irrespectively of the browser.cache.disk_cache_ssl setting.
Version: unspecified → 3.0 Branch
Is this bug claiming that we _do_ honor it for http ? I don't know why the two would be different so I'm curious about why this is specified in the summary. Is there an Expires header on your responses? The spec says the "cache MUST NOT use the entry after it becomes stale", maybe we don't consider it stale yet? Do you have a public server that exhibits this behavior we could test against? If not could you capture an http debugging log and attach it http://www.mozilla.org/projects/netlib/http/http-debugging.html (if you do the latter try not to do too much surfing, the logs get big)
This is a mass search for Firefox General bugs filed against version 3.0 that are UNCO and have not been changed for 200 days. Reporter, please update to Firefox 3.6.10 or alter. Firefox 3.0 is no longer supported and is no longer receiving updates. After you update, please create a fresh profile, http://support.mozilla.com/kb/managing+profiles, and test to see if your bug still exists. If you still the bug, then please post a comment with the version you tested against, and the problem. If the issue is no longer there, please set the RESOLUTION to RESOLVED, WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.