Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > HELP REQ: getting rid of cached webpage

Reply
Thread Tools

HELP REQ: getting rid of cached webpage

 
 
Donchano
Guest
Posts: n/a
 
      01-03-2010

On Sun, 03 Jan 2010 18:13:24 +1300, Max Burke
<(E-Mail Removed)> shouted from the highest rooftop:

>On 2/01/2010 5:32 p.m., Donchano wrote:
>> OS: WinXPpro
>> ISP: Telecom Xtra
>> ADSL Modem: D-Link Model DSL-502T V.C5
>> Wireless Router: Cisco LINKSYS Model WRT-110
>> It started on Christmas Eve day. I updated my website and uploaded the
>> changed page using SmartFTP. No problems. Everything ticked along as
>> usual.

>
>> But when I went to check how the changes looked in FF and IE, the old
>> page loaded without any changes.

>
>> Cleaned both caches, but same thing happened.
>>
>> Cleaned my DSN cache using "ipconfig /flushcache" in run. Rebooted. No
>> luck.

>
>I get the new page on Telstra Clear/Paradise cable in Wellington
>
><Quote>
>THIS PAGE IS UPDATED REGULARLY
>and was last updated on 03 January 2010
>
>Please email new links to: Bob Feigel
><End Quote>



Thanks for checking, Max. Now all I have to figure out is why it took
the changed so long for it to show on my browsers and how I can keep
the problem from continuing to happen.
 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      01-03-2010
Donchano wrote:
> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
> shouted from the highest rooftop:
>
> In retrrospect I'm inclined to believe that the reason the explanation
> worked had little to do with me finding that the cached pages had
> finally stopped loading this morning and that the new, updated pages
> had taken their place.
>
> But the problem persists. I've just updated another page (just to test
> things out) and all I can load in FF and IE is the page as it looked
> before I updated.


You still havent answerd what expiration directives the server is
issuing to the ISPs cache along with the page. If it is giving is
several days before expiry what you are seeing is the expected behaviour.

Trying to troubleshoot ISP caching issues without looking at what your
server is instructing the cache to do is like trying to diagnose a
faulty car without seeing it.
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      01-03-2010
In message <hhq27h$svr$(E-Mail Removed)>, Richard wrote:

> Trying to troubleshoot ISP caching issues without looking at what your
> server is instructing the cache to do is like trying to diagnose a
> faulty car without seeing it.


Back when I was on dialup, I discovered that my ISP had interposed a caching
proxy between me and my client’s web server the hard way.

There was a bug in the proxy, which meant that, whenever I tried to add an
item to the shopping-cart system I was developing, the item got added twice.
I was tearing my hair out trying to figure out what I thought was my bug,
until I thought to check the web server logs, and discovered that the
accesses were coming, not from my IP address, but from something like
“cacheflow.wave.co.nz”. (Pun no doubt intended.)

One simple way to bypass such a proxy seems to be to use an alternative port
other than port 80. You can keep port 80 open for normal accesses by the
general public, but also have your web server listening on another port for
testing purposes. Then you can compare what you see when accessing the same
page via the two different ports.
 
Reply With Quote
 
Donchano
Guest
Posts: n/a
 
      01-04-2010

On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
from the highest rooftop:

>Donchano wrote:
>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>> shouted from the highest rooftop:
>>
>> In retrrospect I'm inclined to believe that the reason the explanation
>> worked had little to do with me finding that the cached pages had
>> finally stopped loading this morning and that the new, updated pages
>> had taken their place.
>>
>> But the problem persists. I've just updated another page (just to test
>> things out) and all I can load in FF and IE is the page as it looked
>> before I updated.

>
>You still havent answerd what expiration directives the server is
>issuing to the ISPs cache along with the page. If it is giving is
>several days before expiry what you are seeing is the expected behaviour.


That's because I don't know how. But since I haven't changed anything
other than a few words of text on each the pages I can think why the
expiration directives would have suddenly changed. As I said earlier,
up until Boxing Day, the changes/updates I made and uploaded used to
visible online within seconds of me publishing them - and have so for
years.

>Trying to troubleshoot ISP caching issues without looking at what your
>server is instructing the cache to do is like trying to diagnose a
>faulty car without seeing it.


Is there somewhere you can point me to that has a tutorial on this?
Because I don't know how to figure out why expiration directives the
server is issuing to Xtra's cache along with the pages.

TIA.
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      01-04-2010
Donchano wrote:
> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
> from the highest rooftop:
>
>> Donchano wrote:
>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>>> shouted from the highest rooftop:
>>>
>>> In retrrospect I'm inclined to believe that the reason the explanation
>>> worked had little to do with me finding that the cached pages had
>>> finally stopped loading this morning and that the new, updated pages
>>> had taken their place.
>>>
>>> But the problem persists. I've just updated another page (just to test
>>> things out) and all I can load in FF and IE is the page as it looked
>>> before I updated.

>> You still havent answerd what expiration directives the server is
>> issuing to the ISPs cache along with the page. If it is giving is
>> several days before expiry what you are seeing is the expected behaviour.

>
> That's because I don't know how. But since I haven't changed anything
> other than a few words of text on each the pages I can think why the
> expiration directives would have suddenly changed. As I said earlier,
> up until Boxing Day, the changes/updates I made and uploaded used to
> visible online within seconds of me publishing them - and have so for
> years.
>
>> Trying to troubleshoot ISP caching issues without looking at what your
>> server is instructing the cache to do is like trying to diagnose a
>> faulty car without seeing it.

>
> Is there somewhere you can point me to that has a tutorial on this?
> Because I don't know how to figure out why expiration directives the
> server is issuing to Xtra's cache along with the pages.
>

If you know how to use a command prompt you may be able to get a bit
more information. See below, pulled from
http://forums.remote-exploit.org/tut...-grabbing.html

It shows how to connect to the server from the command line and get info
back. Note that you might not *see* the 'HEAD / HTTP/1.0' bit and you'll
have to type it blind, follow by a couple of 'enters'.

Cheers,

Cliff

To fingerprint a web server, you should connect to it with a number of
different tools and take make a decision based on the results. On easy
method of fingerprinting a web server is to use netcat or Telnet.

telnet www.victim.com 80

Note that there is a space and the target port number after the DNS name
of the victim server, whatever that may be. This will get Telnet to
connect to the web server service on port 80. Great, now you can type
directly into the Telnet session certain commands that are recognised by
the web server and will illicit a response.

HEAD / HTTP/1.0
This should suffice for most fingerprinting needs. The HEAD command will
return to the Telnet screen the header of the victim server. In the
header will most likely be a line starting with Server:. After that
should be the type of server it is:
Server: Microsoft IIS/5.0
Server: Microsoft IIS/6.0
Server: Apache (Win32) 2.0.32
Server: Apache (Redhat) 1.3.39
And so on.

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.
 
Reply With Quote
 
Donchano
Guest
Posts: n/a
 
      01-04-2010

On Mon, 04 Jan 2010 15:39:07 +1300, Enkidu <(E-Mail Removed)>
shouted from the highest rooftop:

>Donchano wrote:
>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
>> from the highest rooftop:
>>
>>> Donchano wrote:
>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>>>> shouted from the highest rooftop:
>>>>
>>>> In retrrospect I'm inclined to believe that the reason the explanation
>>>> worked had little to do with me finding that the cached pages had
>>>> finally stopped loading this morning and that the new, updated pages
>>>> had taken their place.
>>>>
>>>> But the problem persists. I've just updated another page (just to test
>>>> things out) and all I can load in FF and IE is the page as it looked
>>>> before I updated.
>>> You still havent answerd what expiration directives the server is
>>> issuing to the ISPs cache along with the page. If it is giving is
>>> several days before expiry what you are seeing is the expected behaviour.

>>
>> That's because I don't know how. But since I haven't changed anything
>> other than a few words of text on each the pages I can think why the
>> expiration directives would have suddenly changed. As I said earlier,
>> up until Boxing Day, the changes/updates I made and uploaded used to
>> visible online within seconds of me publishing them - and have so for
>> years.
>>
>>> Trying to troubleshoot ISP caching issues without looking at what your
>>> server is instructing the cache to do is like trying to diagnose a
>>> faulty car without seeing it.

>>
>> Is there somewhere you can point me to that has a tutorial on this?
>> Because I don't know how to figure out why expiration directives the
>> server is issuing to Xtra's cache along with the pages.
>>

>If you know how to use a command prompt you may be able to get a bit
>more information. See below, pulled from
>http://forums.remote-exploit.org/tut...-grabbing.html
>
>It shows how to connect to the server from the command line and get info
>back. Note that you might not *see* the 'HEAD / HTTP/1.0' bit and you'll
>have to type it blind, follow by a couple of 'enters'.
>
>Cheers,
>
>Cliff


Thanks for the heads-up, Cliff.

OK ... I've run the command line, which opened the window into which I
typed the following command:

HEAD / HTTP/1.0

That, in turn, produced the following error:

HTTP/1.1 400 Bad Request
Date: Mon, 04 Jan 2010 3:24:49 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1
Connection to host lost

I got similar errors (with more details) when trying these command
lines as well:

OPTIONS / HTTP/1.0

PROPFIND / HTTP/1.0

I've tried this several times on both my PC and laptop and got the
exact same errors each time.

I remain baffled.
 
Reply With Quote
 
Nik Coughlin
Guest
Posts: n/a
 
      01-04-2010
On 4/01/2010 3:39 pm, Enkidu wrote:
> Donchano wrote:
>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
>> from the highest rooftop:
>>
>>> Donchano wrote:
>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>>>> shouted from the highest rooftop:
>>>>
>>>> In retrrospect I'm inclined to believe that the reason the explanation
>>>> worked had little to do with me finding that the cached pages had
>>>> finally stopped loading this morning and that the new, updated pages
>>>> had taken their place.
>>>>
>>>> But the problem persists. I've just updated another page (just to test
>>>> things out) and all I can load in FF and IE is the page as it looked
>>>> before I updated.
>>> You still havent answerd what expiration directives the server is
>>> issuing to the ISPs cache along with the page. If it is giving is
>>> several days before expiry what you are seeing is the expected
>>> behaviour.

>>
>> That's because I don't know how. But since I haven't changed anything
>> other than a few words of text on each the pages I can think why the
>> expiration directives would have suddenly changed. As I said earlier,
>> up until Boxing Day, the changes/updates I made and uploaded used to
>> visible online within seconds of me publishing them - and have so for
>> years.
>>> Trying to troubleshoot ISP caching issues without looking at what
>>> your server is instructing the cache to do is like trying to diagnose
>>> a faulty car without seeing it.

>>
>> Is there somewhere you can point me to that has a tutorial on this?
>> Because I don't know how to figure out why expiration directives the
>> server is issuing to Xtra's cache along with the pages.
>>

> If you know how to use a command prompt you may be able to get a bit
> more information. See below, pulled from
> http://forums.remote-exploit.org/tut...-grabbing.html
>
>
> It shows how to connect to the server from the command line and get info
> back. Note that you might not *see* the 'HEAD / HTTP/1.0' bit and you'll
> have to type it blind, follow by a couple of 'enters'.


Or use Firefox and you can just use one of the many add-ons for working
with HTTP headers.
 
Reply With Quote
 
Donchano
Guest
Posts: n/a
 
      01-04-2010

On Sun, 03 Jan 2010 17:54:14 +1300, Lawrence D'Oliveiro
<(E-Mail Removed)_zealand> shouted from the highest rooftop:

>In message <(E-Mail Removed)>, Donchano wrote:
>
>> But the problem persists. I've just updated another page (just to test
>> things out) and all I can load in FF and IE is the page as it looked
>> before I updated.

>
>Does the problem also show with wget? Worth trying that, because it takes
>browser peculiarities completely out of the equation.
>
>And does the question-mark trick work?


Thanks, but I'm afraid I'm not familiar with wget or the question-mark
trick.
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      01-04-2010
Donchano wrote:
> On Mon, 04 Jan 2010 15:39:07 +1300, Enkidu <(E-Mail Removed)>
> shouted from the highest rooftop:
>
>> Donchano wrote:
>>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
>>> from the highest rooftop:
>>>
>>>> Donchano wrote:
>>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>>>>> shouted from the highest rooftop:
>>>>>
>>>>> In retrrospect I'm inclined to believe that the reason the explanation
>>>>> worked had little to do with me finding that the cached pages had
>>>>> finally stopped loading this morning and that the new, updated pages
>>>>> had taken their place.
>>>>>
>>>>> But the problem persists. I've just updated another page (just to test
>>>>> things out) and all I can load in FF and IE is the page as it looked
>>>>> before I updated.
>>>> You still havent answerd what expiration directives the server is
>>>> issuing to the ISPs cache along with the page. If it is giving is
>>>> several days before expiry what you are seeing is the expected behaviour.
>>> That's because I don't know how. But since I haven't changed anything
>>> other than a few words of text on each the pages I can think why the
>>> expiration directives would have suddenly changed. As I said earlier,
>>> up until Boxing Day, the changes/updates I made and uploaded used to
>>> visible online within seconds of me publishing them - and have so for
>>> years.
>>>
>>>> Trying to troubleshoot ISP caching issues without looking at what your
>>>> server is instructing the cache to do is like trying to diagnose a
>>>> faulty car without seeing it.
>>> Is there somewhere you can point me to that has a tutorial on this?
>>> Because I don't know how to figure out why expiration directives the
>>> server is issuing to Xtra's cache along with the pages.
>>>

>> If you know how to use a command prompt you may be able to get a bit
>> more information. See below, pulled from
>> http://forums.remote-exploit.org/tut...-grabbing.html
>>
>> It shows how to connect to the server from the command line and get info
>> back. Note that you might not *see* the 'HEAD / HTTP/1.0' bit and you'll
>> have to type it blind, follow by a couple of 'enters'.
>>
>> Cheers,
>>
>> Cliff

>
> Thanks for the heads-up, Cliff.
>
> OK ... I've run the command line, which opened the window into which I
> typed the following command:
>
> HEAD / HTTP/1.0
>
> That, in turn, produced the following error:
>
> HTTP/1.1 400 Bad Request
> Date: Mon, 04 Jan 2010 3:24:49 GMT
> Server: Apache
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
> Connection to host lost
>
> I got similar errors (with more details) when trying these command
> lines as well:
>
> OPTIONS / HTTP/1.0
>
> PROPFIND / HTTP/1.0
>
> I've tried this several times on both my PC and laptop and got the
> exact same errors each time.
>
> I remain baffled.
>

Me too! Hehe! What Operating System is this? Did you type the 'telnet
<URL> 80' first?

Try HEAD / HTTP/1.1 as well.

Cheers,

Cliff

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.
 
Reply With Quote
 
Enkidu
Guest
Posts: n/a
 
      01-04-2010
Donchano wrote:
> On Mon, 04 Jan 2010 16:56:08 +1300, Nik Coughlin <(E-Mail Removed)>
> shouted from the highest rooftop:
>
>> On 4/01/2010 3:39 pm, Enkidu wrote:
>>> Donchano wrote:
>>>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <(E-Mail Removed)> shouted
>>>> from the highest rooftop:
>>>>
>>>>> Donchano wrote:
>>>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <(E-Mail Removed)>
>>>>>> shouted from the highest rooftop:
>>>>>>
>>>>>> In retrrospect I'm inclined to believe that the reason the explanation
>>>>>> worked had little to do with me finding that the cached pages had
>>>>>> finally stopped loading this morning and that the new, updated pages
>>>>>> had taken their place.
>>>>>>
>>>>>> But the problem persists. I've just updated another page (just to test
>>>>>> things out) and all I can load in FF and IE is the page as it looked
>>>>>> before I updated.
>>>>> You still havent answerd what expiration directives the server is
>>>>> issuing to the ISPs cache along with the page. If it is giving is
>>>>> several days before expiry what you are seeing is the expected
>>>>> behaviour.
>>>> That's because I don't know how. But since I haven't changed anything
>>>> other than a few words of text on each the pages I can think why the
>>>> expiration directives would have suddenly changed. As I said earlier,
>>>> up until Boxing Day, the changes/updates I made and uploaded used to
>>>> visible online within seconds of me publishing them - and have so for
>>>> years.
>>>>> Trying to troubleshoot ISP caching issues without looking at what
>>>>> your server is instructing the cache to do is like trying to diagnose
>>>>> a faulty car without seeing it.
>>>> Is there somewhere you can point me to that has a tutorial on this?
>>>> Because I don't know how to figure out why expiration directives the
>>>> server is issuing to Xtra's cache along with the pages.
>>>>
>>> If you know how to use a command prompt you may be able to get a bit
>>> more information. See below, pulled from
>>> http://forums.remote-exploit.org/tut...-grabbing.html
>>>
>>>
>>> It shows how to connect to the server from the command line and get info
>>> back. Note that you might not *see* the 'HEAD / HTTP/1.0' bit and you'll
>>> have to type it blind, follow by a couple of 'enters'.

>> Or use Firefox and you can just use one of the many add-ons for working
>> with HTTP headers.

>
> Would "Live HTTP Headers" be one of those? I've installed it and used
> it to see the Request Headers and Response Headers for a particular
> page, but I haven't a clue what it all means, except that the response
> was OK, the connection is Keep Alive and the age is 34263. I can also
> see that the date of last modification is not correct and displays an
> earlier modification date rather than the latest date (yesterday).
>

Good clue. You are getting that from a cache *somewhere* is my guess.
Can you cut and paste the info from the Response Headers?

(If you have Live HTTP headers you don't need the rigmarole that I
suggested with telnet and HEAD, BTW).

Cheers,

Cliff

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
cause webpage one to reload when webpage two is closed. Paul ASP .Net 14 06-19-2008 03:02 PM
check if a webpage is forwarding to a other webpage martijn@gamecreators.nl Python 1 09-06-2005 02:27 PM
Email contents of webpage or Form on webpage w/o using Server scripting sifar Javascript 5 08-24-2005 05:47 PM
my cached dataset just wont stay cached!! Craig G ASP .Net 0 03-07-2005 10:02 AM
Are my pages getting cached or something? Help very much appreciated! Simon ASP .Net 2 07-17-2004 09:17 PM



Advertisments