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

301 redirects (with default redirect: 'follow') are not cached in v5 #102

Open
glasser opened this issue Nov 28, 2022 · 1 comment
Open

Comments

@glasser
Copy link
Member

glasser commented Nov 28, 2022

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.

glasser added a commit that referenced this issue Nov 28, 2022
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).
glasser added a commit that referenced this issue Nov 28, 2022
@glasser
Copy link
Member Author

glasser commented Nov 28, 2022

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 29, 2022
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 <[email protected]>
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

1 participant