Hi, On 11/21/24 10:37 AM, Felix Moessbauer wrote: > Some clients like apt-cacher-ng cannot handle 302 redirects (at least > in some versions). For them, we must handle the 302 redirects in > varnish. For others, it is better to let the client handle the 302 as > this results in higher cache hitrates (consider moving to the next > snapshot run where only very few packages changed). > > We perform this dispatch based on the presence of the > x-download-directly header which is set by the upstream cache (e.g. > fastly). To keye the backend response of the /archive endpoint, we > inject the Vary header there. Otherwise varnish caches the 302 redirect > and does not hit the dispatch logic ever again.
Thank you, I applied them and pushed them to mlm-01! I had to do a minor fix to include /file/ in Vary handling: When the request is internally retried - i.e. served directly - the output of /file/ was lacking the Vary header. >From my tests this worked! With the caveat that Fastly might still be caching old replies and I had to purge a cache entry manually. The good thing is that Fastly will tell you the Age of the cache entry in the header of the same name. So if it is ancient, it's maybe from before the fix. ;-) Cheers Philipp Kern
