Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >>> Now, the penalty it imposes is annoying. I’ve sometimes found myself >>> working around it, too (because I knew the server was going to have the >>> store item sooner than 1h). >>> >>> Rather than removing it entirely, I can think of these options: >>> >>> 1. Reduce the default negative timeouts. >> >> I think reducing it is good, as you say, it's possible to override the >> default from the server side. Just in case someone wants caching >> behaviour, it might be worth keeping that functionality at least. > > OK, let’s do that. > >>> 2. Add an option to ‘guix publish’ (and to the Coordinator?) so they >>> send a ‘Cache-Control’ header with the chosen TTL on 404. That >>> way, if the server operator doesn’t mind extra load, they can run >>> “guix publish --negative-ttl=0”. >> >> That sounds sensible. The Guix Build Coordinator doesn't do any serving, >> that's left to something else like nginx. For the deployments I maintain >> though, I don't think I'm setting the relevant headers, but I'll look at >> changing that. > > Cool. > >> Going back to the %narinfo-transient-error-ttl, if I'm correct in saying >> that it's not possible to override that, maybe that should also use the >> relevant header value if set? > > Correct, ‘%narinfo-transient-error-ttl’ cannot be overridden. We can > halve it if you think that’s useful, thought when that happens, it means > something’s wrong with the server (returning 500 or similar). > > I’ve sent patches to address this, lemme know what you think! The patches you've sent look good.