SP downloading and xmldsig-validating remote XML metadata on every start

[Peter Schober]

* Scott Cantor <cantor.2 at osu.edu> [2023-03-20 14:19]:
> I tested and verified it's still doing good things.

Thanks, I finally got around to standing up a Rocky VM and was able to
reproduce the findings given the same configuration and server hosting
the metadata. (Not that there was any reason to expect differently.)

> My guess is that you (or whomever) don't have Etag support
> configured on the server and it's not able to detect that the
> resource hasn't changed,

As to server support I stated the following in my original post:

* Peter Schober via users <users at shibboleth.net> [2023-03-17 18:53]:
> The web server hosting the metadata supports last-modified and etag
> HTTP Reponse headers:
> 
> $ curl -sS -I https://example.org/metadata.xml 2>&1 | egrep -i "^(last-modified|etag)"
> last-modified: Fri, 17 Mar 2023 07:12:21 GMT
> etag: "4b1e9ca-5f7134c5a9f40"

And repeated requests against that the same URL (as long as the
metadata remains unchanged) yields the same header values.

> The logic works by issuing a conditional GET based on the Etag
> stored on disk (the cached file with a .tag extension) and if that
> comes back clean, it doesn't download the new one, uses the backup
> and then you get the benefit.
> 
> No Etag or at least no tag file, and you get a new download, so it
> doesn't use the backup unless the main fetch fails.

I'm sure I've seen a .tag file at some point (maybe I'll have to
watch with strace again) but AFAICT the only backup file is being
created with a temp name suffix (e.g. metadata.xml.6f20) and renamed
after signature verification finished.

-peter