Closed Bug 257727 Opened 20 years ago Closed 19 years ago

Hardware URL Redirect is cached inappropriately

Categories

(Core :: Networking, defect)

1.7 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 89419

People

(Reporter: public, Assigned: darin.moz)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

I log into the Internet from hotels frequently. Often these hotels have
"router-based redirects" that take me from the site I want to go to (e.g.
slashdot.org) to the sign in page for internet access (e.g.
http://vbn.0012248.lodgenet.net/common_ip_cgi/Register/register.cgi). So, when I
select "slashdot.org" (or any other URL) it takes me to this other web site.

I register at this other website and then I'm allowed to access any page on the
internet.

The strange behavior is that when I got back to slashdot, the redirect to the
lodgenet page appears to be cached permanently as "slashdot.org" (and since it
instantly redirects me to the lodgenet site, I can't even "refresh" the link to
show it that it's sending me to the wrong place. The only way to fix the problem
is to completely clear the cache inside Firefox.

Reproducible: Always
Steps to Reproduce:
This may be a little hard to create manually since I don't know what kind of URL
redirect the hardware I'm using is sending but i'd guess it's somekind of HTTP
"site permanently relocated" or similar erroneous response.
1. Connect to Internet behind a lodgenet service provider by accessing a page
"foo.com"
2. You are redirected to the lodgenet registration procedure. Register for
internet access.
3. Visit internet sites, and verify you have access to complete internet
4. Visit "foo.com" and see that you are redirected by to lodgenet's original
registration page
5. Clear cache in firefox
6.Visit "foo.com" and see that you can now access "foo.com"



Expected Results:  
Firefox should not cache an HTTP or URL redirect. It should always attempt to
contact the site in question (IMO). This would fix this problem (but there might
be other ways too). 

A novice user will never be able to figure out what's going on with this
problem, so I'd argue this is a "regular" bug rather than a "minor" bug. But
that's just me.
This may be related, and also may give a way to test:

when in apache with mod_rewrite, making change in a rule what url an adress is
redirected to:
- used to rewrite permanent to https://www.oldadress.test
- now changed to rewrite permanent to https://www.newadress.test

Firefox will be redirected to the old adress until the browsers cache is cleared.

(Tested with firefox-1.0_7,1 from ports in Freebsd-5.3.)
You can read about a similar problem here:
http://forums.mozillazine.org/viewtopic.php?t=303367

1. After redirection, the Cache-control headers in the new response are not
considered and the response is still cached improperly.
2. The URL in the Location header is not considered as another URL but as part
of the first response. This way when the location in the Location header is
changed, the browser uses the old URL.
Both refer to improper caching.

I agree that the severity is at least Normal.
Why is this bug still UNCONFIRMED after ONE YEAR?
This is a major functionality bug.
Should I send it as a new one?
Is it that someone doesn't want to check if it exists?
Assignee: firefox → darin
Component: General → Networking
Product: Firefox → Core
QA Contact: general → benc
Version: unspecified → 1.7 Branch
I think you should mark this bug as duplicate of 308296.
The BIG question is why this MAJOR bug is still unresolved as it is known since
2001(!) with a lot of duplicates that are even UNCONFIRMED as this one for one
year!?
Also, maybe the problem is not only with images as described but with any html
response as well?

*** This bug has been marked as a duplicate of 89419 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.