First, thanks for this project.

Second, I'm using this in a build.rs script and trying to figure out a path to forcing the download of an already cached artifact, which may be required for whatever reason.

The regular behaviour of this crate will fetch the ETag on every run, which, in a build script, will mean a network request on every build.

You might think - use freshness_lifetime, and that works, but as-implemented, that serves double duty in the sense that it's both used to check the freshness of a cached artifact AND defines the validity period of a cache.

So with a default freshness_lifetime set to say, 3 days.. an environment variable to force redownload could set it to 0, which will invalidate the cache and fetch the resource, which is great. But the newly fetched resource will also only be valid for that ONE request, after which it will have expired, causing us to check the ETag on every subsequent build, which is the same issue.

An alternative approach, after reading the internal behaviour of this crate (which is subject to change), is to check if the birthtime of the path returned by cached_path is earlier than now, then manually delete the artifact archive and the -extracted suffixed folder, then call cached_path again. But that's overdoing it.

So I was thinking, could we maybe decouple the responsibility of freshness_lifetime? and have a dedicated expire_after or something to that effect?