567581 - Firefox doesn't cache pages with "Vary: Cookie" header

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Alain Knaff]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3

If a page returns a "Vary" header, firefox doesn't cache it at all, instead of just considering the headers enumerated in "Vary" to be additional lookup keys.

It works fine with Squid.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.lll.lu/~aknaff/bug-reports/mozillaVary/
2. Click on set cookie to 1
3. Click on read cookie
4. Click on read cookie again
5. Click on set cookie to 2
6. Click on read cookie again.
7. Click on set cookie to 1
8. Click on read cookie again.

Actual Results:  
At step 4, the date changes.

Expected Results:  
The date should stay the same at step 4 => does not work.
At step 6, the cookie value should be shown as 2 (and the date changed) => works ok
At step 8, the cookie value should be shown as 1, and the same would ideally be the same as on step 3 => does not work


The read-cookie echoes back current date and the cookie.
It sets Cache-Control: max-age=3600 to make sure that the page can be cached.
It also sets a Vary: Cookie header

It works fine when surfing through squid, which basically caches a different version per cookie value.

"In the wild", Vary headers are used by many CMS'es (such as Plone) and similar software in order to support different page contents for different spoken languages, or for giving a different vision to logged-in users that for unauthenticated users. This firefox behavior means that pages served by such software cannot be cached, leading to a negative performance impact.

If it is too difficult to implement a cache that is indexed by headers as well as URL, maybe we could settle for a half solution where the request headers of the cached version would be stored along with the contents, and the entry would be considered stale if the headers of the new request didn't match the one of the previous. This would fix the problem at step 6 (common case), although still triggering a refetch at step 8.

Comment 1

[Alain Knaff]

Actually, further tests show that apparently the issue is only with Vary: Cookie, but not with other headers in Vary.

It does work correctly (according to half-fix outline above) for Accept-Language (tested by changing language in the prefs).

It also works for Accept-Encoding (no refetch, couldn't test however whether it would honor any changes, as I don't know how to do influence what Accept-Encoding is sent).

It also works for User-Agent (no fetch if it isn't changed, refetch if changed via the User-Agent switcher add-on)

It also works for non-existant headers (Vary: NoSuchHeaders), where it doesn't refetch.

So it looks as if the issue is specifically related to the Cookie header.

Comment 2

[Alain Knaff]

Observed in the wild:

http://groups.google.com/group/django-developers/browse_thread/thread/5ad30acc497ecfd1

Comment 3

[Jo Hermans]

See the explanation in nsHttpChannel::ResponseWouldVary(), which you can find in <http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/src/nsHttpChannel.cpp> (line 1288).

I think it's a dupe of bug 468426 ; there should still be a cache, but it's validated again.

Comment 4

[Tyler Downer [He/Him]]

Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode? If not, please close. These links can help you in your testing.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Managing+profiles

You can also try to reproduce in Firefox 4 Beta 8 or later, there are many improvements in the new version, http://www.mozilla.com/en-US/firefox/all-beta.html

Comment 5

[Alain Knaff]

Just tried it on 3.6.13 using the very clear test scenario I included in the description, and the problem still happens.

Comment 6

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.13 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.

Comment 7

[Alain Knaff]

Note: when testing this, don't use a proxy. Otherwise it will appear to be working correctly, but in reality it's the proxy who caches it, rather than Firefox.

Comment 8

[Alain Knaff]

In 18.0.2, this seems to work (no refetch if cookie didn't change, refetch when it does change), thanks.

However, it doesn't keep several VARYants in memory at once (indexed by cookie). I.e. when changing from 1 to 2, and then back to 1, it fetches a new copy, instead of re-using one that it may have had from before it went to 2.

Squid does cache different variants at once (date goes back in time when going back to a variant that was visited earlier)

So it looks like my "half solution" described in the last paragraph of my report was implemented.