Add no-cache headers to PersistedQuery error responses

[ryandrewjohnson]

Issue:

Since both PersistedQueryNotSupportedError and PersistedQueryNotFoundError are considered HttpGraphQL errors they will respond with an http status code of 200 with no cache-control headers set. This causes issues when you have a CDN like CloudFront sitting in front of your Apollo Server as it will hold onto these errors, which results in subsequent responses being served the cached error response.

Fix:

When either PersistedQueryNotSupportedError or PersistedQueryNotFoundError is thrown the following cache-control header is added to the response preventing it from being cached:

'Cache-Control': 'private, no-cache, must-revalidate'

For more details please see the Spectrum chat with discussion on the issue:
https://spectrum.chat/apollo/apollo-server/cloudfront-caching-persistedquerynotfound-error-responses~b615361e-53f2-4771-a3d2-d04fb9349246

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

[apollo-cla]

@ryandrewjohnson: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[mikelau13]

thx Ryan, that's exactly what I need!

[ryandrewjohnson]

@abernix @martijnwalraven any chance this can make it in for the next release? This addresses the bug we discussed on Spectrum https://spectrum.chat/apollo/apollo-server/cloudfront-caching-persistedquerynotfound-error-responses~b615361e-53f2-4771-a3d2-d04fb9349246.

We have an app in production that we've had to remove Persisted Query functionality due to this bug. In the interim we've had to revert back to plain GET requests, with the plan to activate persisted queries again once this is merged/released.

[ryandrewjohnson]

@abernix really hoping to get some feedback on this?

[abernix]

Apologies for the delays! I've left a couple comments, but this seems generally correct to me. I'll do a bit more looking into it before merging, but I'd be keen on putting this into an alpha of Apollo Server 2.5.0 for testing (see #2482).

[ryandrewjohnson]

@abernix thanks for taking a look at this! That would be amazing if it could make it in for the alpha release of alpha 2.5.0.

[ryandrewjohnson]

@abernix just pushed latest fix. This should be good to merge now - thanks!

[abernix]

Thanks for this PR!

It's been published in [email protected] — and the various integrations like apollo-server-express, apollo-server-hapi, etc. — of the same version!

[ryandrewjohnson]

Thanks for this PR!

It's been published in [email protected] — and the various integrations like apollo-server-express, apollo-server-hapi, etc. — of the same version!

@abernix any guesstimate on when this release will officially drop?

[abernix]

The more feedback about the alpha the more confident we can be with promoting it to “latest”. Anything that would be keeping you from trying the alpha?

[ryandrewjohnson]

@abernix I think we could probably put the alpha version in, and see how it goes. Are there any known breaking changes?

[abernix]

@ryanmaxwell Nope! These are the changes at the current time: https://github.com/apollographql/apollo-server/milestone/17?closed=1