In Firefox 3.6, the SSL font used by https://addons.allizom.org is properly cached. In Firefox 4 (nightlies and beta 7) the font is re-downloaded every page load when navigating around the site. I have reproduced this behavior on other sites with SSL as well. I didn't see this change documented in Firefox 4 for Developers, so I'm not sure if it's intended or if it's a regression.
I can't reproduce this on trunk. If I load https://addons.allizom.org/en-US/firefox/?browse=featured in a clean profile and then focus the url bar and hit enter, I see this in the HTTP log: 1892969632[1028138b0]: Not validating based on expiration time 1892969632[1028138b0]: nsHTTPChannel::CheckCache exit [this=129ddf330 doValidation=0] 1892969632[1028138b0]: nsHttpChannel::ReadFromCache [this=129ddf330] Using cached copy of: https://www.mozilla.com/img/fonts/MetaWebPro-Black.woff and no HTTP request dispatched to the server. If I then quit the browser and start it again against the same profile I see similar output. Do you see this issue in a clean profile?
I see the same thing you do following your STR. But the main problem we're seeing, including in a new profile, is: 1. load homepage 2. click on any other link, for example, one of the categories on the left 3. the font is downloaded again every single page you go to
Oh, I see. The server's response for that font file includes: Vary: Referer, Accept-Encoding So any time you load it with a new Referer we have to revalidate, per spec; I think that between 3.6 and 4.0 we did fix Vary handling to work correctly. It also returns a response with a different Etag when requested with different referrers, so it really has to return a new 200 response instead of a not modified.
Ah, ok, thanks! Sounds like we should fix the Vary header then.
Component: Networking: Cache → Public Pages
Product: Core → addons.mozilla.org
QA Contact: networking.cache → web-ui
Alright, discussed this with mozilla.com and AMO folks. Summary of the issue is that Firefox 4 users are downloading the entire font file on every page of AMO and mozilla.com because of changes to the way the Vary: referer header works in Firefox 4. We use this header because the font shop requires us to check the referer to make sure only our sites can use the font. As this issue is only going to get worse as more people use Firefox 4, we need a solution very soon. John, it looks like our referrer checking is no longer feasible. How would you like to proceed?
Assignee: nobody → jslater
Severity: normal → critical
OS: Mac OS X → All
Hardware: x86 → All
Summary: SSL font caching behavior changed? → Fonts on Mozilla sites aren't cached in Firefox 4
I've passed the issue over to Ivo at FontShop...will let you know what our options are there and then we can decide how to proceed.
If they insist on the Referer thing, could you keep the Vary header but send back the same ETag (or a 304 not modified if the ETag already matches) on every request that's allowed to get the font file? That would would still mean we have the latency of the roundtrip for the validation request, but would move a lot less data on the wire.
Also note Bug 620688.
The vary Referer problem is not specific to FF4. The referer field is set to the page request in FF 3.6 as well.
We heard back from the font shop and they are fine making an exception for us. We can remove the referrer check.
Assignee: jslater → abuchanan
On trunk, Sending .htaccess Transmitting file data . Committed revision 79972.
Moving this bug to websites:www.mozilla.com, since that's where the change is landing.
Component: Public Pages → www.mozilla.com
Product: addons.mozilla.org → Websites
QA Contact: web-ui → www-mozilla-com
Summary: Fonts on Mozilla sites aren't cached in Firefox 4 → Remove font file referrer check and vary header
I confirmed with production Mozilla.com that we kept re-issuing GET requests for: http://www.mozilla.com/img/fonts/MetaWebPro-Black.woff, with headers: Vary:Referer, Accept-Encoding X-Backend-Server:pp-web04 X-Cache-Info:caching On trunk, I see only one request (Firefox caches the font file now, if my testing is right); headers are now: Vary:Accept-Encoding X-Backend-Server:dm-cms03 X-Cache-Info:not cacheable; response specified "Cache-Control: private"
Keywords: qawanted → push-needed
qa-verified-trunk (sorry for forgetting to mark that).
r79989 on production
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Verified FIXED on prod: Vary:Accept-Encoding X-Backend-Server:pp-web04 X-Cache-Info:caching
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Product: Websites → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.