checkForUpdates interacts badly with the CDN

[edsko]

[09:42:32] also, the CDN has this nasty effect of delaying all hackage changes by a few minutes [09:42:44] ... which for most people of course doesn't make much of a difference [09:42:58] although, that said [09:42:59] hm [09:43:05] currently when hackage-security updates [09:43:09] it will of course contact hackage [09:43:17] but it contacts it through the CDN, I guess? [09:43:20] yeah [09:43:21] I mean, we took no steps not to [09:43:24] so that's bad [09:43:46] we quite intentionally pick a single mirror for the entire update process [09:44:00] because you don't want to read, say, timestamp.json from one host and snapshot.json from another [09:44:06] yeah [09:44:09] but with the CDN in places, that's probably precisely what we end up doing anyway [09:44:16] now if this throws a security error, we will try again [09:44:20] with a maximum of 5 iterations [09:44:43] and after the first iteration we set a Cache-Control: max-age=0 header [09:44:43] I wonder if we can disable the CDN for a couple of files

[edsko]

It would probably be sufficient if the reverse proxy respected the max-age header.