619767 - Remove font file referrer check and vary header

Status: VERIFIED FIXED

(www.mozilla.org :: General, defect)

Description

[Justin Scott [:fligtar]]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Justin Scott [:fligtar]]

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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Justin Scott [:fligtar]]

Ah, ok, thanks!

Sounds like we should fix the Vary header then.

Comment 5

[Justin Scott [:fligtar]]

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?

Comment 6

[John Slater]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Steven Garrity [:sgarrity]]

Also note Bug 620688.

Comment 10

[Michael Gauthier [:gauthierm]]

The vary Referer problem is not specific to FF4. The referer field is set to the  page request in FF 3.6 as well.

Comment 11

[Justin Scott [:fligtar]]

We heard back from the font shop and they are fine making an exception for us. We can remove the referrer check.

Comment 12

[Alex Buchanan [:abuchanan]]

Attachment: patch v1, remove referrer check from .htaccess

Comment 13

[Alex Buchanan [:abuchanan]]

On trunk,

Sending        .htaccess
Transmitting file data .
Committed revision 79972.

Comment 14

[Alex Buchanan [:abuchanan]]

Moving this bug to websites:www.mozilla.com, since that's where the change is landing.

Comment 15

[Stephen Donner [:stephend] Not actively reading bugmail]

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"

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

qa-verified-trunk (sorry for forgetting to mark that).

Comment 17

[Alex Buchanan [:abuchanan]]

r79989 on production

Comment 18

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on prod:

Vary:Accept-Encoding
X-Backend-Server:pp-web04
X-Cache-Info:caching