Closed Bug 293188 Opened 19 years ago Closed 19 years ago

When Firefox is redirected using http headers, it caches the url and does not update when the redirect header is changed. It will always go to the old redirected url.

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Version:
1.7 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: wills-bugzilla, Assigned: darin.moz)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

One of my domains has a redirect on it using hdaccess and mod rewrite.

For example: MyDomain.com gets redirected to myseconddomain.com/blah

I then updated this recirect when moving parts around on my site.
On internet explorer, the new redirect works fine. But not on firefox

Example: Mydomain.com is being redirected to myseconddomain.com/newlocation in
Internet Explorer
Mydomain.com is still being redirected to myseconddomain.com/blah in Firefox.

This problem only seems to occur when firefox is redirected using a HTTP
redirect header (not meta refresh for example). Mod rewrite uses these headers
to redirect the browser.
The problem is that the "new" address is stored and not updated (when the "new"
address changes) unless you clear all information from the options page.

Reproducible: Always

Steps to Reproduce:
1. Create a mod rewrite redirect
2. Visit the place where you will be redirected
3. See where your being redirected too
4. Change the redirect
5. Revisit the place where you will be redirected



Expected Results:  
Should update
Assignee: nobody → darin
Component: File Handling → Networking: HTTP
Product: Firefox → Core
QA Contact: file.handling → networking.http
Version: unspecified → 1.7 Branch
Mozilla will cache redirects according to RFC 2616.  You can help us resolve
this bug by capturing a Mozilla HTTP log using the instructions on this page:
http://www.mozilla.org/projects/netlib/http/http-debugging.html

Please attach the resulting log file to this bug report.  Thanks!
Was this a 301 redirect (Moved Permanently) or a 307 (Temporary Redirect) ? Were
there other headers that could influence the caching (Expires, Cache-Control, ...) ?
Wills, can you please answer the questions in comment 1 and comment 2?

Note that mod_rewrite uses 302 responses, and those are cacheable, in general.
Oh woops. Sorry, I completely forgot about this bug report after my vacation.
Here we go with mod rewrite tests:
--------------------------------------------------------------
/blahtest (tmp redirect)

HTTP/1.1 302 Found
Date: Fri, 10 Jun 2005 16:14:01 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2
mod_bwlimited/1.4 PHP/4.3.11 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
Location: http://google.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

--------------------------------------------------------------
/blahtest (permanent redirect)

HTTP/1.1 301 Moved Permanently
Date: Fri, 10 Jun 2005 16:15:16 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2
mod_bwlimited/1.4 PHP/4.3.11 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
Location: http://google.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1


I got send to google.com on that first redirect.
I then modified the redirect to redirect to http://amazon.co.uk
I refreshed the page. If it had chached it would of gone to google.
It actually went to http://amazon.co.uk - so it appears firefox isnt caching 301
redirect.
You mean not caching 302?  Or did you mean "second" when you said "first"?
I meant second. Sorry for being confusing. I modified the top of my post and
forgot to change the bottom bit.

I got send to google.com on that SECOND redirect.
I then modified the redirect to redirect to http://amazon.co.uk
I refreshed the page. If it had chached it would of gone to google.
It actually went to http://amazon.co.uk - so it appears firefox isnt caching 301
redirects.
Ok.  So what is being cached, exactly?
Nothing.

I cannot explain this behaviour. A fried has also tested this on the new alpha
build of firefox, with the same result.
Maybe someone more expeirenced than me can look into this...
Can't explain which behavior?  The bug was filed saying that something is being
cached. Now you're saying that nothing is being cached, which should be correct
given the headers your server is sending.  So what's the issue, then?

Okay. It was caching before. I guess it was a permanent redirect so firefox was
caching correctly.

Now it isnt. This is what I can't explain. I thought I had made myself clear.
Obviously not.
I cant understand why it is now not caching the redirect (on two independen pcs).
Do have to visit the link several times before it caches or something?
Im completely confused.
> Now it isnt. This is what I can't explain.

Per HTTP spec temporary redirects are only cacheable if they have explicit
Cache-Control or Expires headers.  Yours don't.

Sounds to me like everything is working as it should.
Wait Wait Wait.

Im talking about my PERMANENT caching tests. They are NOT caching!

THIS:

HTTP/1.1 301 Moved Permanently
Date: Fri, 10 Jun 2005 16:15:16 GMT
Server: Apache/1.3.33 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2
mod_bwlimited/1.4 PHP/4.3.11 FrontPage/5.0.2.2635 mod_ssl/2.8.22 OpenSSL/0.9.7a
Location: http://google.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

...does NOT cache!

THE SAME THING WAS CACHING BEFORE... Now it is NOT.
I dont know what im doing wrong, or if firefox has to be redirected like 10
times before it will cache and redirect automaticly... I have no clue.
That response doesn't seem to include any information (eg Expires,
Last-Modified, etc) headers that would permit calculation of an expiration time,
so there is no reasonable way to cache it.

In any case, the issue the bug was _filed_ on seems to not exist anymore, so
resolving worksforme until it's possible to reproduce that.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Okay.

Explain this:
It cached (with the case which the bug was filed under) with EXACTLY the same
headers.

You have not tested this with mod rewrite and a permanent redirect so I cant see
how you can say "it works for me".

Can somebody else please test this, using mod rewrite or simular headers. Thank you.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I thought you tested a current build with mod_rewrite and had no problems.  If
not, then what is comment 4 about?

As in, if you're still seeing the bug, what build are you seeing it in, and in
what circumstances?
Firefox Version: 1.0.4. 
Tests done are the same in Comment 4 and Comment 12. 12 is a quote from 4.

A friend tested in the alpha build with the same result.

You are confusing me now.. Cant you test it with the same headers and see if you
get a cache?

> Firefox Version: 1.0.4. 

OK.  Please do test the Deer Park preview in the future?  Testing anything off
the Gecko 1.7 (Firefox 1.0) branch is pretty pointless -- that code is well over
a year old.

> Cant you test it with the same headers and see if you get a cache?

I don't, which looks correct to me.  Again, you filed a bug because caching
_was_ happening, apparently.  Now you're telling me that it actually doesn't
happen (which is correct given the data you've shown me).  What's the bug?  If
you're asking me what was different about your server configuration before when
caching happens, I have no idea what that could have been; there are several
options for getting redirects to cache, per the HTTP RFC, and I have no idea
which one your server was using.

AGrrhh. This is like the 5th time.

1. The server config has not been modfied
2. The headers are exactly the same
3. It cached before.
4. Now its not caching
5. The headers are exactly the same
6. The headers are exactly the same
7. Im using the same apache version as I was then
8. Im using the same mod rewrite version as I was then
9. They are both permanent redirects.

Now, please answer my question: Does firefox need to be redirected by a
permanent redirect several times before it caches?
No.  The caching behavior does not depend on the number of redirects.

If the server config is the same yet behavior changed, then either the client
configuration was changed or something very very odd is going on.  In either
case, we'll need more information to be able to do anything about it.
I havnt changed anything in my firefox settings or downloaded any new plugins
for it.
My friend tested in the new alpha build with the same result.

This is why I can't understand what is going on. It cahced before.. but not now...
I didnt do anything differently or anything.

What more information do you need? I think someone else should test it to make
sure ive not done something totally dumb.
Information on how to reproduce the problem (caching when we shouldn't be
caching).  If no one can reproduce it, then the bug is worksforme.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

(In reply to comment #13)
> That response doesn't seem to include any information (eg Expires,
> Last-Modified, etc) headers that would permit calculation of an expiration time,
> so there is no reasonable way to cache it.
> 
> In any case, the issue the bug was _filed_ on seems to not exist anymore, so
> resolving worksforme until it's possible to reproduce that.

no, 301 is cached forever by default.  cache headers may be used to alter the
default.

one more comment, 301's are reloaded (or revalidated) when the user refreshes
the page.  So, I think everything is working as expected here.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.