Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let redirects be short-term cachable #66

Open
da2x opened this issue Sep 3, 2015 · 2 comments
Open

Let redirects be short-term cachable #66

da2x opened this issue Sep 3, 2015 · 2 comments

Comments

@da2x
Copy link

da2x commented Sep 3, 2015

Please let redirects themselves be temporary cachable by clients. Seems unnecessary for each client behind a proxy to require to refresh the redirects every time.

I’d suggest to make it cachable for 5 or 10 minutes. Should reduce load on httpredir.debian.org and speed up upgrades in proxied environments with many clients. I don’t really know what the ideal time would be, but at least five minutes.

Cache-Control: max-age=450  # 7,5 minutes
@2vek
Copy link

2vek commented Sep 10, 2015

Wouldn't this kill parallel downloads? debian bug#158486

Having no cache is feature actually, see httpredir homepage under "Advantages over mirror:// method"

Per-request decision making: no need to apt-get update to choose a different mirror.

@rgeissert
Copy link
Owner

The redirections that are served with a 307 status are really not meant to be put in a time-driven cache. The files, or objects, behind those names are replaced in-place and it is the redirector the one that is controlling the view that is presented to the user.

I would be happy to add an etag or similar that would allow the proxy to cache to revalidate the response if proxies actually support that, but TTBOMK they don't. Moreover, apt sends a cache-control: must-revalidate for all the indexes - which are the most relevant files for which a 307 is used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants