"Anthony Jones" wrote:

> 
> "Rich-F" <RichF@d...> wrote in message
> news:87E90413-86A6-4F82-8FF3-68A546152B8C@m......
> > "Anthony Jones" wrote:
> >
> > >
> > > "Rich-F" <RichF@d...> wrote in message
> > > news:EE64C55B-B026-46E7-8974-FE8FAAE1C0A4@m......
> > > > "Anthony Jones" wrote:
> > > >
> > > > >
> > > > > "Rich-F" <RichF@d...> wrote in message
> > > > > news:61C826B1-E1F2-4E6F-87FF-83C675E9FDF4@m......
> > > > > > "Anthony Jones" wrote:
> > > > > > <snip>
> > > > > >
> > > > > > > The point I was trying to communicate is that a browser offers
> the
> > > user
> > > > > the
> > > > > > > opportunity to override the normal operation of the local cache
> by
> > > using
> > > > > the
> > > > > > > refresh button.  This causes all requests to fulfill the page to
> > > pass
> > > > > > > through local cache to the origin server regardless of whether
> there
> > > is
> > > > > > > fresh instance of the resource in the cache.
> > > > > > >
> > > > > > > I'm trying to implement a similar feature for resources that
> have
> > > been
> > > > > > > fetched with XMLHTTP.  For performance reasons I do not want to
> send
> > > a
> > > > > > > request every time it's needed however I want to offer the user
> the
> > > same
> > > > > > > 'refresh' option.
> > > > > > <snip>
> > > > > >
> > > > > > Just considering this last point.....
> > > > > >
> > > > > > The only method that worked reliably for me was adding the
> > > > > If-Modified-Since
> > > > > > header and making sure that the date I used was definitely older
> than
> > > any
> > > > > > timestamp that might be associated with the file.  (I used IE6 and
> > > > > > XMLHTTP.3.0)
> > > > >
> > > > > Ok thanks for the input.  However since changing the
> If-Modified-Since
> > > in
> > > > > that way would always result in 200 response from the server and
> never a
> > > 304
> > > > > it's the same is simply using the the load method on a DOM with
> > > ForceResync
> > > > > enabled which is what I was hoping to avoid.
> > > >
> > > > (we're going round in circles here)
> > >
> > > Yes we are
> > hmmmmm.
> > >
> > > >
> > > > If you want to absolutely force the request to go to the server then
> set
> > > > If-Modified-Since to something really old.
> > > >
> > > > If you want to give the server a chance to reply with a 304 then set
> > > > If-Modified-Since to the 'real' modified date as per my previous code
> > > example.
> > >
> > > Your previous code example knew what the 'real' modified date is from a
> > > previous fetch. As I pointed out in response to that; trapping,
> persisting
> > > and retrieving that piece of information is a complication way beyond
> the
> > > worth of the feature.
> >
> > Sometimes, to achieve a simple result you have to put in a
> disproportionate
> > amount of leg-work.
> >
> > > I've also already stated that I'm not seeing the results in my testing
> that
> > > you appear to be.
> > > I've tried setting the If-Modified-Since header but it doesn't force a
> round
> > > trip to the server.
> >
> > Works for me.
> 
> Can't see how that works.  What are the initial response headers? You've
> managed to convince it to perform a trip to the server for a fresh resource
> and get a 304 back?
 
Yes.

Calling getAllResponseHeaders after the initial request yields:

X-Powered-By: ASP.NET
Content-Type: text/xml
ETag: "de88217716dc71:1093"
Content-Length: 590
Last-Modified: Fri, 23 Mar 2007 17:31:02 GMT

The HTTP status was 200.

After setting the If-Modified-Since request header (to the value in the 
Last-Modified response header), calling getAllResponseHeaders after 
subsequent requests yields:

Server: Microsoft-IIS/5.1
Date: Thu, 05 Apr 2007 15:35:16 GMT
X-Powered-By: ASP.NET
ETag: "de88217716dc71:1093"
Content-Length: 0

The HTTP status was 304.

If I then modify the XML file on the server I'll get an HTTP 200 status (and 
the content obviously) and the headers will look the same as the initial 
request (except that clearly the dates will have changed!), and so on and so 
on.

> >
> > >This is as I would expect, the modification date of a resource has no
> bearing on the resources age in the cache.
> >
> > The wording of that sentence suggests to me that you've misunderstood the
> > effect/purpose of the header.
> 
> That's interesting perhaps you can put me straight, this is how I understand
> it:-
> 
> The purpose of the Last-Modified header is to indicate that last time the
> resource changed on the origin server.
> The purpose of the If-Modified-Since header is to indicate to the server (be
> that the origin or a intermediate cache) the last revision of the resource
> the client has in its local cache.  It allows the server to respond with an
> empty 304 status which basically means 'go ahead and use that its still the
> latest version'.
> 
> The Cache-Control header can contain a max-age value which indicates how
> long a resource may be considered fresh before the client must re-validate
> the resource with the server.   The age of the cached resource is not
> dependant on it's Last-Modified date but rather on the last time it was
> validated or fetched from the server.
> 
> Can you correct any misunderstanding in the above?

I don't like some of the wording, but essentially it appears correct, the 
wording in that earlier sentence doesn't reflect the same facts.

> > The overall tone of your responses indicates that you know enough to solve
> > this by yourself, - the best of luck to you.
> 
> I came to the conclusion in an earlier post that the answer to my original
> question is 'no'.

At the moment, I have to conclude that the answer is 'yes' ;-)