«

On Sun, 03 Jan 2010 18:13:24 +1300, Max Burke
<> 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.

Donchano wrote:
> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
> 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.

In message <hhq27h$svr$>, 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.

On Mon, 04 Jan 2010 01:23:54 +1300, Richard <> shouted
from the highest rooftop:

>Donchano wrote:
>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>> 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.

Donchano wrote:
> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <> shouted
> from the highest rooftop:
>
>> Donchano wrote:
>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>>> 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.

On Mon, 04 Jan 2010 15:39:07 +1300, Enkidu <>
shouted from the highest rooftop:

>Donchano wrote:
>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <> shouted
>> from the highest rooftop:
>>
>>> Donchano wrote:
>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>>>> 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.

On 4/01/2010 3:39 pm, Enkidu wrote:
> Donchano wrote:
>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <> shouted
>> from the highest rooftop:
>>
>>> Donchano wrote:
>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>>>> 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.

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

>In message <>, 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.

Donchano wrote:
> On Mon, 04 Jan 2010 15:39:07 +1300, Enkidu <>
> shouted from the highest rooftop:
>
>> Donchano wrote:
>>> On Mon, 04 Jan 2010 01:23:54 +1300, Richard <> shouted
>>> from the highest rooftop:
>>>
>>>> Donchano wrote:
>>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>>>>> 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.

Donchano wrote:
> On Mon, 04 Jan 2010 16:56:08 +1300, Nik Coughlin <>
> 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 <> shouted
>>>> from the highest rooftop:
>>>>
>>>>> Donchano wrote:
>>>>>> On Sun, 03 Jan 2010 14:26:13 +1300, Enkidu <>
>>>>>> 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.