|Cache On Updated Site Will Not Clear|
| 6:17 pm on Jun 19, 2009 (gmt 0)|
Ok, this is a strange problem to me and I cannot find any answers.
I updated one of my sites, changed it to a Wordpress blog. I can see the updated site on my AOL browser ONLY. I've looked at my site on Firefox, Opera, IE, and Safari and they ALL keep showing the old site.
I have cleared caches on my browsers to no avail. I don't like to use AOL for much except email and I want to see this site on my other browsers as it is now, but cannot do this. I even went so far as to do a System Restore and that did not even clear it.
What else can I do and WHY on earth would every other browser show the old site when the worse browser (AOL) shows the updated site.
Thanks for any help.
By the way, if it matters, I am using Vista 64 bit home edition.
[edited by: WolfLover at 6:18 pm (utc) on June 19, 2009]
| 6:30 pm on Jun 19, 2009 (gmt 0)|
Is it the same ISP with all browsers? If AOL-browser is with AOL & all other browsers are with the same (but not AOL) ISP, then that ISP is running a badly-configured Proxy server--probably deliberately--which is set to retain pages.
I've previously experienced this via users of the downloads-section of my site. Despite carefully-crafted headers, some people could never see the difference between a logged-in/not-logged-in page. I had to switch the process from GET to POST to fix it. Another possible route to prove this to yourself is to switch from HTTP to HTTPS, which should also fix it.
If it is your ISP, your only route will be to change ISP.
| 7:28 pm on Jun 19, 2009 (gmt 0)|
This all assumes that the site is configured to return proper cache-control response headers in the first place.
A very quick and dirty method to identify caching issues is to append an arbitrary query string to the URL, or add an arbitrary name/value pair to an existing query string. Since the URI has changed, this request won't be served from the browser cache or cause network caches to return previously-cached data.
To examine the cache-control headers returned with your pages, the Live HTTP Headers add-on for Firefox/Mozilla browsers is quite useful.
| 7:33 pm on Jun 19, 2009 (gmt 0)|
Well, my other browsers are using ATT Fast Access DSL. The AOL browser is from the AOL isp.
| 9:12 pm on Jun 19, 2009 (gmt 0)|
Ok, I took your advice jdMorgan and I am using the Live HTTP Headers add-on for Firefox.
I don't really understand this very well, but here is what I am getting:
Render Mode: Quirks mode (on other sites it says Standards Compliance mode)
RESPONSE: HTTP/1.1 404 NOT FOUND
I really don't know what to look for here.
This is a site where I used to use a dropship type service on and the DNS had been set to their server and you chose their products, etc. I have not used this site in years and yesterday decided to change it to a wordpress blog.
So for a long time, if anyone had gone to my site, they would have seen a page that said this store no longer exists.
Like I said, going through AOL's browser, I get the updated website, but using Firefox, Safari, IE, and Opera, I get the old page on ALL of them!
I have cleared the cache, history, everything.
I have gone to the command prompt and pinged this site.
When I ping the site using MY domain name, I get the response that I have pinged the OLD HOSTS domain name, then "requests time out" appears 4 times, then it says:
Ping Statistics for (*** *** *** ip address):
Packets Sent = 4 ¦ Packets Received = 0 ¦ Packets Lost = 4 (100% loss)
I contacted my isp which is ATT Fast Access as AlexK suggested, and we tried all kinds of things including the command prompt mentioned above, starting in safe mode, etc. etc. etc.
They said they had not ever heard of this problem. They looked at my site in IE and it shows up with the new site fine.
Does anyone have any clue as to why I can see the updated site on AOL's browser, but not on any of the other browsers?
[edited by: WolfLover at 9:15 pm (utc) on June 19, 2009]
| 2:22 am on Jun 20, 2009 (gmt 0)|
|When I ping the site using MY domain name, I get the response that I have pinged the OLD HOSTS domain name, then "requests time out" appears 4 times [...] |
So this sounds like a DNS problem, or perhaps you have mapped your domain name to the old IP address in your local 'hosts' file. Check your DNS record in your zone file, and check your local hosts file.
| 11:31 am on Jun 20, 2009 (gmt 0)|
|that ISP is running a badly-configured Proxy server--probably deliberately--which is set to retain pages. |
I'm embarrassed at the above. More accurate, and less prompted by past bruises & difficulties:
|that ISP--or some other host along the network route--is possibly running a badly-configured Proxy server. |
Jim is far better moderated in his tone & experience than I am. As he says, the above does assume that the HTTP headers returned by the website server are accurate for timely caching.
Does Vista use the same Hosts layout as XP? If so, you will find it at:
(it is called `hosts', and the contents will over-ride all external DNS responses when resolving FQDNs to IP address).
The above needs to be checked out first; Jim has given his usual excellent, accurate advice. My personal experience remains sound, however: at one time my site received requests for a resource removed from static HTML pages more than a year before. Adding a `?sid=' query to the URLs mentioned in my first post did not (apparently) fix the problem. Switching from GET to POST did fix it, and later consideration of the Red-Hat practice suggested that a switch from HTTP to HTTPS pages would have done the same. Such mis-configuration saves the Proxy host a great deal of bandwidth + speed of response, which inevitably leads to the suspicion that some could be deliberate.
| 12:33 pm on Jun 20, 2009 (gmt 0)|
No doubt that some caching proxies are deliberately mis-configured. I'm quite sure that this is true of AOL when caching images, for example, regardless of the cache-control headers on image fetch responses. So I'm not sure that the above 'softening of tone' was really necessary... :)
I was proposing appending a query string to the URL only as a quick and dirty test technique, and not as any kind of solution; By changing the URI each time, you effectively by-pass all caches. In this case, such a test would serve to eliminate the client-side AOL/non-AOL browser factor from the problem equation. Having done that, and having confirmed that the server returns proper cache-control headers, it would be much more likely that the problem was 'out in the middle' in the form of a network caching proxy.