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)
Tracking
()
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
Updated•19 years ago
|
Assignee: nobody → darin
Component: File Handling → Networking: HTTP
Product: Firefox → Core
QA Contact: file.handling → networking.http
Version: unspecified → 1.7 Branch
Assignee | ||
Comment 1•19 years ago
|
||
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!
Comment 2•19 years ago
|
||
Was this a 301 redirect (Moved Permanently) or a 307 (Temporary Redirect) ? Were there other headers that could influence the caching (Expires, Cache-Control, ...) ?
Comment 3•19 years ago
|
||
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.
Comment 5•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
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...
Comment 9•19 years ago
|
||
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?
Reporter | ||
Comment 10•19 years ago
|
||
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.
Comment 11•19 years ago
|
||
> 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.
Reporter | ||
Comment 12•19 years ago
|
||
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.
Comment 13•19 years ago
|
||
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
Reporter | ||
Comment 14•19 years ago
|
||
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 → ---
Comment 15•19 years ago
|
||
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?
Reporter | ||
Comment 16•19 years ago
|
||
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?
Comment 17•19 years ago
|
||
> 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.
Reporter | ||
Comment 18•19 years ago
|
||
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?
Comment 19•19 years ago
|
||
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.
Reporter | ||
Comment 20•19 years ago
|
||
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.
Comment 21•19 years ago
|
||
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.
Comment 22•19 years ago
|
||
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/
Assignee | ||
Comment 23•19 years ago
|
||
(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.
Description
•