[apollo-datasource-rest] HTTPCache incorrectly caches 302 redirects

[gburgett]

In package apollo-datasource-rest, the datasource is incorrectly storing a 302 redirect with the caching headers supplied by the final resource. Then when the request is checked, the original URL is assumed to be fresh and it does not check the original redirect again. This goes against the HTTP spec for 302 redirects (and caused a problem for me in my app)

I've created an integration spec that demonstrates the problem in my fork: https://github.com/gburgett/apollo-server/blob/rest-caching/packages/apollo-datasource-rest/src/__tests__/integration.test.ts

To reproduce:

• Set up a REST API with a 302 redirect to some static resource with cache-control: public, max-age=31536000, immutable
• Issue a GraphQL query that performs a GET request to this 302 redirect path
• Change the 302 redirect to point to another resource
• Issue the same GraphQL query again

At this point, the expected behavior is that the new resource is returned. The actual behavior is that the old resource is served from the HTTP cache.

Our current workaround is to set the TTL to 0 in the caching options for this data source.

[glasser]

There's two things going on here.

The first issue is that there are two layers of caching in Apollo Server and one of them is basically a sledgehammer that caches all GETs forever. We are going to fix that in #100.

However, this is going to reveal the opposite issue — we won't cache any redirects at all (assuming you don't change the redirect Fetch option to manual) because we will only see the final response, not the pre-redirect response. So we also won't cache 301 responses. I'll open a new issue.