Having said that, using Navigator, as I do most of the time (except when I am using Opera or OmniWeb on the Mac and the experience has been exactly the same with them), when I returned to the zoneedit site without actually quitting my browser (which is when it will definitely request a new login) I have been able to continue editing the zones in the active account without a problem. The changes have been for real.
So I don't think that you are seeing cached pages as such, because the changes that you make to the site are for real - you can test this and prove it to yourself - but it simply hasn't logged you out of the session.
Personally, because I have many different zones I am often going to, I find it a hassle to have to quite my browser just to get the login again. I thought I had tried refreshing the page with no resulting login, but I'll try that next time myself - it would certainly save me annoyance if it was that easy to get a nw login screen.
Garth
At 08:26 19/07/02 -0700, you wrote:
Hey Garth:________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
I must have just missed your post as I shut down for the night.
The cacheing problem that I experienced is: using the zoneedit site, once
logged on and making changes if you click around, using the menu that is
available to you on the site (not the back button), you may be viewing pages
that are cached within the site. Here's an example:
-- log onto the site;
-- click on one of your zones to edit;
-- view the A record
-- close the browser window (there is no logoff that I could see)
-- go back to the site, go to the logon screen but don't log on
-- click to edit the same zone that you were in
-- the site will appear to show you the zone, however, it's a cached copy
-- do a CNTRL-R to refresh and bingo, you are presented with the logon
screen again.
Other viewing sequences can be more problematic. I thought my changes would
not take, as I added mail servers to a record twice, because I was viewing a
cached copy of the settings in my browser.
I say it's their issue to solve, because they need to create unique URLs for
every link on their site, just like the rest of us need to, to prevent
browser (and router and proxy and firewall) cacheing issues between the user
and the server. We use a hash of the currenttimestamp appended as an
argument. If the link comes from a static page, we append an argument
containing a large random number, generated in the browser.
If the above is not clear, feel free to ask.
... and thanks again for your help ..
cheers,
Ian
-----Original Message-----
From: Garth Penglase
What exactly do you mean, cached pages? As in cached pages on their site,
or cached pages on your sites? I use Navigator and Opera and using their
service, have never had a problem updating entries.
What prob did you experience?
V. interested in this email from you, since I have recently been having
caching problems with caching on a client tango admin site which includes
uploads causing it to not work exactly as developed.
Garth
At 01:08 19/07/02 -0700, you wrote:
>To Garth, Ben, Mark and others ... thanks !!
>
>This has been a great exploration of DNS the last couple of days.
>
>And the winner is .. zoneedit.com ... by a country mile. They were
>recommended by a friend elsewhere, too. I think most of the DNS hosting
>options I checked had the feature list you mentioned below, Garth.
However,
>I think zoneedit strikes the right balance for me between security and
>price. They also integrate nicely with OpenSRS, which I also use.
>
>One downside: In setting up a couple of domains with them this evening, I
>did notice that they suffer terribly from cached pages. Meaning, you must
be
>very careful when editing pages, to ensure that you aren't viewing a cached
>page with the wrong settings. In our development here, it's an issue that
>we have wrestled pretty much to the ground (and talked to death on this
list
>previously).
>
>Thaks again.
>Ian
>
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
