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

The versions disk cache and http cache headers #6538

Closed
lbargaoanu opened this issue Feb 6, 2018 · 4 comments
Closed

The versions disk cache and http cache headers #6538

lbargaoanu opened this issue Feb 6, 2018 · 4 comments

Comments

@lbargaoanu
Copy link

lbargaoanu commented Feb 6, 2018

While using RestoreCommand and repeatedly publishing new versions of a package, we've noticed that new versions are not found and the restore fails. We always request the latest published version. This seems to be because the results of the queries for package versions are cached on the disk. But the responses for those requests send HTTP cache headers that say the results should not be cached. I think the on disk cache should respect those cache headers. We get the same behavior in VS with PackageReferences. Related to #5445. But deleting nuget.cache doesn't help, only clearing the cache. I guess the workaround is to set SourceCacheContext.MaxAge to DateTime.UtcNow.
NuGet.Commmands version 4.5.

@emgarten
Copy link
Member

emgarten commented Feb 6, 2018

It looks like you found the correct way to disable caching when calling the restore APIs.

At this time caching is a client policy, changing this to use the server policy instead would likely cause performance problems for most users.

//cc @joelverhagen

@joelverhagen
Copy link
Member

Hey @lbargaoanu, could you provide a bit more context on your issue?

  1. What package source are you working with? NuGet.org does send back cache headers in some case but these are not intended for official NuGet client to consume (they are actually meant for our CDN).
  2. Since it seems you are using NuGet as a library rather than nuget.exe, could you use HttpCacheUtility to delete blobs that you don't want (or perhaps changing their last write timestamp to be a long time ago)? This could be a way of explicitly invalidating parts of the cache you don't want.

As @emgarten said, in the NuGet ecosystem caching is designed to be a client policy. Since many of our customers work in a multi-feed environment, having caching as a client policy means better consistency and better performance when sources wouldn't otherwise properly implement cache headers.

Also, the MaxAge to DateTime.UtcNow seems like a decent solution for you.

@lbargaoanu
Copy link
Author

lbargaoanu commented Feb 7, 2018

Yes, we have multiple feeds too and I did notice they send different headers. But we do have control on the feed that gets updated and causes the problem. Thanks for the tips. I guess I'm missing more granular control. I just want to be able the restore the latest versions, otherwise the cache is great :) We'll look more closely to see what MaxAge will do for us.

@lbargaoanu
Copy link
Author

Closing as #3389 seems the gist of it.

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