User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 When visiting a page that allows content negotiation, such as the above apache page, the cache, ETags etc are not cleared when a user's language preferences change. Thus changing your Accept-Language string and clicking refresh does not result in a new page being show, but a 304 and the stale cache version displayed. Reproducible: Always Steps to Reproduce: See above Actual Results: See above Expected Results: See above

Reporter, do you still see this problem with the latest Firefox 2? If not, can you please close this bug as WORKSFORME. Thanks!

No response from reporter re: comment 1 -->INCOMPLETE. Reporter, if you still see this problem with the latest release of Firefox 2, please reopen this bug. Thanks!

Don't close it yet. I didn't even see your previous comment until now. Yes, the bug still exists in FF 2.0.0.3, i just checked. Load the URL above, note the HTTP headers that get sent. Set your Accept-Language string to something else in about:config Reload the page, and note the new headers. You should see that the new Accept-Language was sent, but also that the If-Modified-Since and If-None-Match headers are still sent.

Are you able to test with a trunk build at all? - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I can still reproduce this bug with FireFox 3.0.3. I have set up a test page here to show it: http://www.dracos.co.uk/code/firefox-bug/ This appears similar in scope to bug 269303, where I now discover I said the same thing in September 2007 :) https://bugzilla.mozilla.org/show_bug.cgi?id=269303#c32

Is it close enough to mark as a duplicate?

Assuming it is.