Forum

V10.0 - Windows XP
How do I completely disable the caching of files served?

I have already tried:
CacheSize = 0

When I restart Hiawatha, the files in /work/gzipped/ are all deleted. But then, files start appearing again.

The CacheSize option is for the in-memory cache. The /work/gzipped/ data is for serving gzipped-content-encoded files. This last one can't be disabled.

I understand you to say the /work/gzipped/ folder simply holds compressed files to be delivered to the client.

May I assume that Hiawatha makes a determination if the original file no longer matches the gzipped file's contents?

Yes, based on the last-changed timestamp. If the original file has been changed, the gzipped version is removed and a new one will be created.

Is this noticing of the last-changed timestamp affected by CacheSize or any other setting?

I was having major problems just before my posting on this forum with a javascript file being swapped out for a previous version (v2), and not getting that previous version but the version that was just swapped out (v3).

It is possible that (v2) had an _earlier_ timestamp compared to (v3). So, there may be the possibility that comparing timestamps misses certain inequalities.

This post (https://www.hiawatha-webserver.org/forum/topic/2138) suggests only a _later_ filetime, not always a _different_ filetime.

Yes, later indeed, It depends how this previous version was placed back. With a move, the last-change timestamp is not changed. So, yes, that could cause an issue. Simply 'touch' a file to solve this issue.

In Windows, there is no 'touch'. There is a "Last Accessed", which I would think is the closest. But, I have no idea what "status.st_mtime" would equate to in Windows. Probably "Last Modified".

I would make a request that the code be:
if (status.st_mtime != gz_status.st_mtime) {

Sometimes I move a file from a dev directory to the production directory, sometimes I rename a temporarily named file back to it's original, sometimes I revert a file back from the version control repository.

No, != is not correct. The gzipped version is always newer than the original file, because Hiawatha creates it.

I see that the logic is correct in the existing if statement.

I propose a means of validating the GZ file against the source based on some factor other than, or in addition to, the file's modified time. This is assuming modifying the file (in Windows), for the sole purpose of creating a current modified timestamp on that file, is not convenient or not allowed.

Perhaps making part of the gzipped filename, the epoch timestamp of the source file. For example (simplified):
Source: /path/xyz.txt having an epoch timestamp of 12345
GZipped filename result of hash("12345/path/xyz.txt")

Then compare for "not equal".

You're sure it's not a browser cache issue?

I mentioned above, I switched off the browser's cache to eliminate that as a possibility.

Even so, the browser can be forced to reload all page resources (CTRL-F5, or Shift-Click the Reload icon), verified by watching the network traffic tool in Firebug, and in Firefox's own internal Web Developer tools.

Sorry. I *thought* I mentioned switching off the browser's cache. Perhaps I did write that, but then deleted it as being irrelevant prior to posting the message.

Open src/target.c and change the line 142 from

if (status.st_mtime > gz_status.st_mtime) {

to

if ((status.st_mtime > gz_status.st_mtime) || (status.st_ctime > gz_status.st_ctime)) {

This should solve your issue. I assume you use v10.1, otherwise the line number can be slightly different.

First let me say: thank you.

Second, I am sorry to say I am in no position to compile C code on Windows.

But now that I know where the "stale" content is coming from, I can routinely delete the files in the gzipped folder as necessary.

If you send a message to hugo@hiawatha-webserver.org, I'll reply with a patched Windows package.

That's very kind of you.