"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)

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.