how to clear cached encoding information?

RESOLVED WORKSFORME

Status

()

Firefox
General
RESOLVED WORKSFORME
9 years ago
8 years ago

People

(Reporter: Harald Dunkel, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [CLOSEME 2011-1-30])

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b3) Gecko/20091120 Firefox/3.6b3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2b3) Gecko/20091120 Firefox/3.6b3

How can I tell firefox to forget cached encoding information?

Reproducible: Always

Steps to Reproduce:
1.setup apache with "AddEncoding x-gzip .gz .tgz"
2.do "ls -l /usr/bin | gzip >/var/www/subdir/listing.gz"
3.open "http://myhost/subdir/" in firefox, and click on "listing.gz". You will be asked what to do with the gzip file. Cancel, but keep firefox running.
4.replace the AddEncoding from step 1 by "AddType application/x-gzip .gz .tgz", and restart apache
5.do shift-leftclick on "http://myhost/subdir/" to reload the page, and click on "listing.gz"

Actual Results:  
it still asks what to do with the gzip page

Expected Results:  
firefox should recognize the "application/x-gzip" and gunzip "listing.gz" on the fly
clear the cache should work but you can not force a reload if you get a file download dialog.  

>firefox should recognize the "application/x-gzip" and gunzip "listing.gz" on
>the fly

AFAIK Apache is using only the filedate for the cache headers and changing the content-type configuration doesn't change that. Apache still reports that Firefox cached copy is still valid: This is an Apache bug
Does it work if you change the filedate ?
(Reporter)

Comment 2

9 years ago
> clear the cache should work but you can not force a reload if you get a file
> download dialog.  
> 

Showing the file download dialog is the bug. The cache check should be done before choosing between download dialog and showing the gunzipped text.

> AFAIK Apache is using only the filedate for the cache headers and changing the
> content-type configuration doesn't change that. Apache still reports that
> Firefox cached copy is still valid: This is an Apache bug
> Does it work if you change the filedate ?

No, touching the *.gz file doesn't help.

Does firefox send the mime type back to apache when checking the cached version? Do other http servers perform better together with firefox?
(Reporter)

Comment 3

9 years ago
Seems that I mixed up AddEncoding and AddType. Here are the correct

Steps to Reproduce:
1.setup apache with "AddType application/x-gzip .gz .tgz"
2.do "ls -l /usr/bin | gzip >/var/www/subdir/listing.gz"
3.open "http://myhost/subdir/" in firefox, and click on "listing.gz". You will
be asked what to do with the gzip file. Cancel, but keep firefox running.
4.replace the AddType line from step 1 by "AddEncoding x-gzip .gz .tgz",
and restart apache
5.do shift-leftclick on "http://myhost/subdir/" to reload the page, and click
on "listing.gz"
>Showing the file download dialog is the bug. The cache check should be done
>before choosing between download dialog and showing the gunzipped text.

Sure, the cache check is done before.
My comment is an answer to your question :
"!How can I tell firefox to forget cached encoding information?"

a) If a document is cached, how long a document is cached or if it should not be cached at all depends on the http headers send by the server for the document.
b) Firefox validates the cache with an if-modified header 
c) You can use a shift+reload/ctrl+f5 to do a forced reload with will bypass the cache but that its not possible if you get a download dialog
d) you can clear the Firefox cache as last option

Again, please provide the http header for the subdir/listing.gz file before and after the change.

>Does firefox send the mime type back to apache when checking the cached
>version?
A client will never send a content-type in a get request, only for post reuqests because.
Firfefox sends an If-Modified-Since header and that doesn't contain a content-type because it's a get request. 

read for example http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
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
Whiteboard: [CLOSEME 2011-1-30]
(Reporter)

Comment 6

8 years ago
3.6.13 still shows this problem, but for 4.0beta8 it seems to be gone.
We will close as it is fixed in 4. This is not a security problem so it won't be backported to 3.6
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.