Re: Some data related to the frequency of cache-busting

On Tue, 3 Dec 1996, Robert S. Thau wrote:

> Unfortunately, use of server-side-include type schemes (what .shtml is
> typically meant to invoke) is not always so easy to detect --- the
> Apache web server, for instance, has hooks which allow the same sort
> of processing to be applied to *.html files with certain unusual Unix
> permission bit settings (XBitHack), and there are people who run the
> server configured to treat *all* *.html files as (potentially)
> containing server-side includes.  Deliberate cache-busting (e.g., to
> enable collection of better metrics) may not be the intent of these
> setups, but they currently have something of that effect...

XBitHack is set to allow cacheing of SHTML. If the server has this 
enabled, and the file has the group excute bit set, then the page is 
served with the last-modified date of the container file. It's up to the
webmaster to update the modification date to the container file when
any included files change. I use this extensively (user-configurable
pages where the included file grows, setting PICS headers, common header
and footer information on thousands of pages, etc.). 

Anawat has recently pointed out to me, though, that Content-Length does 
not get set, which will cause a persistant connection to be dropped at
the end of the document.
I confess that persistant connection is something I haven't really looked 
at - it's not supported in many of the browsers and agents I've used.

Re. action - in Apache one can define a new suffix and pseudo-mime-type
which will redirect to a CGI script. I made one so that 
/some/doc.lang would go to /cgi-bin/redirect-lang/doc.lang and thence
to /some/english.html, /some/french.html etc. as a semi-cacheable
alternative to the Apache content-negotiation using  .var suffix, which
plain doesn't work with cache in HTTP 1.0


Received on Wednesday, 4 December 1996 16:55:47 UTC