Forcing retrieval of a fresh copy of a file with a link

[Don]

Is it possible to create a link which will cause either A) the server
to serve a fresh copy of a file or B) the browser to "refresh" the
copy of the file.

Doing it via a link is the only possibility that I think would be
viable for our situation, as changing HTTP headers isn't really
feasible/desired right now (think 'expires' or 'no-cache'). Also, the
file is non-HTML, so adding a 'no cache' meta tag to the file itself
won't work. The file in question has no file extension and contains
text-only excerpts from Apache access logs; parsing it as HTML or PHP
causes it to jumble the line endings and cram everything up, making it
unreadable.

So...Is there a way to add something to the A HREF= tag or create some
other sort of link that can do this? We're also open to other
possibilities which don't involve HTTP headers (or at least the
modification of .htaccess, httpd.conf, etc.).

[Andy Dingley]

On 30 May, 13:47, Don <don...@gmail.c omwrote:

Is it possible to create a link which will cause either A) the server
to serve a fresh copy of a file or B) the browser to "refresh" the
copy of the file.

Yes and no.

HTTP is "RESTful" (look it up), which means that you can't do this (as
stated). There's a link on a page which tells you the URI by which to
retrieve that web resource. What happens when you try to retrieve that
URI-identified resource is entirely up to the server that serves the
file in response to the URI. If it "thinks that you need" a new file,
it can send you one. Otherwise it will send the old file again, or
send headers that indicate to the browser it can continue to use the
old one. There's no "flag mechanism" alongside the URI to indicate
"Yes, I really want a new one", certainly not one that a HTML page
with an embedded <a href="..." can send to the browser.

OTOH, if there are multiple URIs that return the same file, but that
look dissimilar to naive browsers, then it's very easy to hack your
way past this. Try mangling the URI with an extra meaningless query
parameter. This will usually make a cache (internal to the browser or
external) treat this as a separate web resource, but the server will
end you the same content and the browser will download and store it
equally.

e.g. replace
<http://example.com/files?docid=123 4>
with
<http://example.com/files?docid=123 4&cache_buster= foo657658765576 56>
The real way though is to configure the server (.htaccess isn't that
scary) so as to return HTTP Response headers indicating that the file
shouldn't ever be cached, or (better) that it has a very short expiry
lifetime.

[Don]

[...snip...]

AWESOME post, Andy! For right now I'm trying putting the UNIX time
stamp at the end of the file request (as in http://example.com/searchfile2?1212158868).
Hopefully that works for what we need. This is for work and it's just
an internal utility that my boss and I use to look at part of the
access logs, so I guess it's not really mission critical and doesn't
need to be all that robust (although I suppose that in practice, being
in the habit of creating robust code/systems would be a good idea).

Since it's for work and the server hosts one of our company's
websites, I'd definitely like to be more comfortable with editing the
config files before I start playing around with the HTTP headers
in .htaccess or httpd.conf or wherever. I'll probably poke around in
the Apache install I have on one of my home Linux machines.

Thanks again!

[Andy Dingley]

On 30 May, 15:52, Don <don...@gmail.c omwrote:

Since it's for work and the server hosts one of our company's
websites, I'd definitely like to be more comfortable with editing the
config files before I start playing around with the HTTP headers
in .htaccess or httpd.conf or wherever.

So long as you learn and test with .htaccess, you can only screw-up
the sub-tree beneath where you're editing. To break the whole server
requires httpd.conf