Closed
Bug 198594
Opened 21 years ago
Closed 12 years ago
DNS: "shift-reload" should reload DNS cache too, and be documented
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
FIXED
People
(Reporter: garsh, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030302 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030302 The "reload" button has the effect of telling the browser to ignore the cache and to talk to the server to fetch the page. It should also tell the browser to ignore the DNS cache. Otherwise, the only way to force the browser to get new DNS information immediately is to shut it down and restart it. I know there are several *similar* PR's dealing with DNS caching, but I didn't see any that specifically say that the reload action should cause the cache to be ignored. Please don't mark this as a DUP unless the original PR specifically mentions this. Reproducible: Always Steps to Reproduce: 1. Access a web site 2. Change that web site's IP address & DNS entry 3. Try reloading the page Actual Results: mozilla keeps trying to access original IP address Expected Results: mozilla should refetch dns information and access new IP address.
Reporter | ||
Updated•21 years ago
|
Summary: DNS cache should be ignored for "reload" → DNS cache should be ignored & updated for "reload"
-> NEW, +clean-report That is a really good idea. I wish I had thought about it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: clean-report
Summary: DNS cache should be ignored & updated for "reload" → DNS: "reload" should reload DNS cache too
I like this idea, but I think it should be tied to "shift-reload" rather than a simple reload. It could be tricky to implement. When loading a page via shift-reload, ideally we would only flush those DNS cache entries requested by the page, and only the first time they are requested. Currently the DNS Service doesn't have access to the state, and doesn't have an interface to clear a specific DNS entry. Adding a flag to flush a DNS entry would be easy to add, but then well need to change doc loader or layout to use it. Of course, the socket transport also caches dns results, which may make the cache in nsDnsService completely redundant. I'm not sure if it's feasible for the socket transport to cooperate in the "flush DNS cache on reload". Darin, what are your thoughts on this concerning the socket transport?
Status: NEW → ASSIGNED
Comment 4•21 years ago
|
||
i like this idea too, but definitely only for the shift-reload case, since i think javascript can cause a normal reload to occur. we'd need to check the LOAD_BYPASS_CACHE load flag on each channel. getting this to be done only for the first occurance of a domain per overall page load will be very tricky since we don't have any existing machinery for that in necko, save for the loadgroup. we could perhaps tack on some info to the loadgroup. or we could maybe just add a minimum freshness time to the cache(s) such that a shift-reload would be ignored if a DNS lookup had not sat in the cache long enough. that would mostly suffice if tuned correctly (which is a big "IF" i know). as for the socket transport's cache, remember that the DNS service is actually wedged behind the socket transport. so, in order for the channel's to cause the DNS's cache to be bypassed, the channel's would have to pass some info to the socket transport that it would have to then pass onto the DNS service. so, the socket transport would necessarily know what is going on =)
Reporter | ||
Comment 5•21 years ago
|
||
I *strongly* disagree with doing this for shift-reload. It should be done whenever the user requests a reload. You are making a bad assumption - the assumption is that the user even knows of the existence of shift-reload. The user does not. I still don't know what shift-reload does. When I search for "shift reload" in mozilla help, it turns up nothing. The user knows about the reload button, and they know about the reload menu item under the "View" menu. That is all. If you want javascript reloads to not affect the DNS cache, then make javascript reloads behave differently than UI reloads.
These are somewhat independent. I think clearly yes for shift-reload. Reload sounds desirable to some, but my understanding is that there is an assumption that reload always causes network-level events to fire, and I don't think this is true in all cases.
Comment 7•21 years ago
|
||
benc: no, reload always means talk to the server. sometimes that only means talk to the proxy server. but, we always try to make sure that the user sees the most up-to-date copy of the document following a reload.
darin: thanks for the extra info. I might have been thinking a little bit about "refresh", which in Communicator may not have re-loaded from the network. The other point I was mulling is that reload is for most situations (load that file again), while shift-reload has more application when the user feels the expected data is not going to arrive unless a more comprehensive, lower-level set of events are triggered to reload the file. It sounds like we all agree here, so I've changed the summary.
Summary: DNS: "reload" should reload DNS cache too → DNS: "shift-reload" should reload DNS cache too
Comment 9•21 years ago
|
||
Reassigning bug to owner and QA contact of selected component, as gordon is 'gone', adding doc request to summary (Should be offshoot bug?). FYI, some good news: Bug 192798 (DNS: Offline->Online does not clear the DNS cache) has been fixed.
Assignee: gordon → darin
Status: ASSIGNED → NEW
Summary: DNS: "shift-reload" should reload DNS cache too → DNS: "shift-reload" should reload DNS cache too, and be documented
Comment 10•21 years ago
|
||
I've experienced this quite a bit as well (most recently today). Would be nice if Mozilla/Firebird would support ignoring DNS info (and retrieving fresh) when the shift key is used. It makes sense, considering it should completely refresh the information, ignoring all cashe.
Comment 11•21 years ago
|
||
This could be considered a security problem. Here's the situation: A user looks up an intranet host on a laptop, puts the laptop to sleep, and moves to a different network. The user then thinks he has VPN'd back to the intranet, but the connection fails for whatever reason. The user then attempts to access the same intranet site, but gets a completely differenent host (same private IP). If that host was malicious, it could attempt to steal login information from the user. (If it isn't malicious, it is still confusing to the user.) I propose deleteing the _entire_ DNS cache if the hosts DHCP assigned ip address changes. Or at least if the subnet changes.
Comment 12•21 years ago
|
||
Tom: new bug please. The cache expires by default after 60 seconds.
Comment 13•21 years ago
|
||
(In reply to comment #12) Bug 232335 has been entered, as requested.
Updated•20 years ago
|
OS: Linux → All
Hardware: PC → All
Comment 14•20 years ago
|
||
*** Bug 166146 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 277829 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Assignee: darin → nobody
QA Contact: benc → networking
Comment 16•12 years ago
|
||
shift-reload forces that host's dns entry (or the proxy's dns entry) to be looked up in cache bypass mode (which will then update the cache).
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•