301 redirects (with default redirect: 'follow') are not cached in v5
#102
Comments
glasser
added a commit
that referenced
this issue
Nov 28, 2022
RESTDataSource contained a memoization cache (separate from the HTTP-header-sensitive shared cache) which caches all GET requests forever. This wasn't even documented for the first four years of RESTDataSource's existence and led to a lot of confusion. In this new major version, this cache will instead by default only de-duplicate *concurrent* GET requests. This also introduces `deduplicationPolicyFor()` which lets you tune how de-duplication works, including restoring v4 semantics (see the changeset for code snippets). Fixes #40. Fixes #72. Fixes #73. Fixes #46. Fixes #39 (though it "introduces" #102). Somewhat addresses #65 but only for the de-duplication cache (we should still allow direct control over the cache key for the HTTP).
|
Mm, it's not exactly precise to say this was introduced by v5. The memoization cache could cache the combination of the initial and redirected GETs in v5, but we wouldn't cache the 301 in the shared cache back then either. |
glasser
added a commit
that referenced
this issue
Nov 29, 2022
RESTDataSource contained a memoization cache (separate from the HTTP-header-sensitive shared cache) which caches all GET requests forever. This wasn't even documented for the first four years of RESTDataSource's existence and led to a lot of confusion. In this new major version, this cache will instead by default only de-duplicate *concurrent* GET requests. This also introduces `deduplicationPolicyFor()` which lets you tune how de-duplication works, including restoring v4 semantics (see the changeset for code snippets). Fixes #40. Fixes #72. Fixes #73. Fixes #46. Fixes #39 (though it "introduces" #102). Somewhat addresses #65 but only for the de-duplication cache (we should still allow direct control over the cache key for the HTTP).
glasser
added a commit
that referenced
this issue
Nov 30, 2022
RESTDataSource contained a memoization cache (separate from the HTTP-header-sensitive shared cache) which caches all GET requests forever. This wasn't even documented for the first four years of RESTDataSource's existence and led to a lot of confusion. In this new major version, this cache will instead by default only de-duplicate *concurrent* GET requests. This also introduces `deduplicationPolicyFor()` which lets you tune how de-duplication works, including restoring v4 semantics (see the changeset for code snippets). Fixes #40. Fixes #72. Fixes #73. Fixes #46. Fixes #39 (though it "introduces" #102). Somewhat addresses #65 but only for the de-duplication cache (we should still allow direct control over the cache key for the HTTP). Co-authored-by: Trevor Scheer <trevor.scheer@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before v5 (not quite released as I file this issue) all GETs got cached forever. In v5 we are fixing that (#100) which fixes the reported issue (#39) that 302s (temporary redirects) were being cached.
However, this introduces the new issue that 301s (permanent redirects) are now not being cached. That's because (assuming use have the default
redirect: 'follow'in your fetch request) RESTDataSource only sees the response from the final request, not any intermediate request.Fixing this would require us to implement redirect support ourselves which is probably not a great idea, so this may be more of a "documentation of an issue" than something that's likely to be fixed.
The text was updated successfully, but these errors were encountered: