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. Signed-off-by: Felix Moessbauer <[email protected]> --- .../roles/templates/snapshot/snapshot.debian.org.vcl.erb | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/modules/roles/templates/snapshot/snapshot.debian.org.vcl.erb b/modules/roles/templates/snapshot/snapshot.debian.org.vcl.erb index e93ee0437..57e9c283e 100644 --- a/modules/roles/templates/snapshot/snapshot.debian.org.vcl.erb +++ b/modules/roles/templates/snapshot/snapshot.debian.org.vcl.erb @@ -30,8 +30,14 @@ sub vcl_purge { } sub vcl_backend_response { + # Only if x-download-directly is present, we task varnish to follow + # the redirect internally. Otherwise forward to client to get better caching + if (bereq.url ~ "^/archive/") { + set beresp.http.vary = "x-download-directly"; + } if (bereq.http.host != "snapshot-dev.debian.org" && bereq.retries == 0 && + bereq.http.x-download-directly && beresp.status == 302 && beresp.http.location ~ "https?://[^/]*/file/") { set beresp.http.location = regsub(beresp.http.location,"^https?://",""); @@ -41,6 +47,7 @@ sub vcl_backend_response { } if (bereq.http.host != "snapshot-dev.debian.org" && bereq.retries == 0 && + bereq.http.x-download-directly && beresp.status == 302 && beresp.http.location ~ "^/file/") { set bereq.url = beresp.http.location; -- 2.39.5
