Closed sftcd closed 1 year ago
I'm scripting up -02 now (as a bash script as it happens) and don't see how to either set or get the HTTP freshness lifetime, using relevant tooling and likely permissions so I think we need to add some timing information back into the JSON. For now, I've added a "regenfreq" element that says how often (in seconds) the bash script is called via cron.
Re: tooling, you can get the headers in a reasonably accessible form with
curl -o save -w '%{header_json}' https://example.com/
From there it's "just" a simple matter of extracting the "age" and "max-age" values and subtracting them.
I'm OK with skipping this header business and just sticking the lifetime into the object somehow, but perhaps we should get some advice from the HTTPAPI group.
I'm OK with skipping this header business and just sticking the lifetime into the object somehow, but perhaps we should get some advice from the HTTPAPI group.
Hm. Do we want to assume that the key lifetime is kept in sync with the HTTP header? I’m okay if so, but we should make it explicit.
Yep, could use curl go read something, but no idea how to do the write to a web server. Anyway, yeah, let's put a value in the JSON. I'll make changes thusly - don't think we need to use a PR yet as the entire JSON thing will in any case need to be discussed/munged by the WG sometime later.
WRT "key lifetime" - actually what I think we want is "regeneration frequency" which may be a bit different. Turning that into a DNS TTL is the ultimate goal but 'till that's done by the ZF it's advice really and not likely to change quickly or often.
Made that change in b50a2da - look good enough for now?
I would call this a "regeneration interval", rather than "frequency", but it's fine with me. Effectively we're just saying that this lifetime is approximate, and as long as it's not wildly wrong it'll be fine.
no strong opinion about interval v. frequency (will change to the former next time I edit 'less someone says otherwise) and probably close this issue too then.
made that s/regenfreq/regeninterval/ change in https://github.com/sftcd/wkesni/commit/cd69e917d5532633b1c5b0ef8598102ee565a376 so closing this now.
Our current -01 text says "The zone factory observes that the JSON resource has an HTTP freshness lifetime of 3600 seconds," We don't necessarily need to answer this right now, but that's not clear as to how that 3600 is determined. It'd also be much better if that's something that can be accessible via a command line invocation of curl, otherwise I think I'd argue to revert to how -00 had suggested TTLs. The text we have for now is fine for now though.