You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Apollo Server 2, plugins could not set HTTP response headers for HTTP-batched
operations; the headers would simply not be written in that case.
In Apollo Server 3, plugins can set HTTP response headers. They have
access to individual `response.http.headers` objects. In parallel, after
each operation is processed, any response headers it sets are copied to
a shared HTTP response header object. If multiple operations wrote the
same header, the one that finishes its processing last would "win",
without any smart merging.
Notably, this means that the `cache-control` response header set by the
cache control plugin had surprising behavior when combined with
batching. If you sent two operations in the same HTTP request with
different cache policies, the response header would be set based only on
one of their policies, not on the combination of the policies. This
could lead to saving data that should not be cached in a cache, or
saving data that should only be cached per-user (`private`) in a more
public cache.
In Apollo Server 3, we are fixing this by restoring the AS2 behavior:
never setting the `cache-control` header for batched operations. While
this is in a sense backwards-incompatible, the old behavior was
nondeterministic and unpredictable and it seems unlikely that anyone was
intentionally relying on it.
(In Apollo Server 4, we will instead make improvements (in v4.1.0) that
allow the cache control plugin to merge the header values across
operations. This is not feasible in Apollo Server 3 because the data
structure manipulation is more complex and this would be a serious
backwards incompatibility to the plugin API.)
As part of this, a new `requestIsBatched: boolean` field is added to
`GraphQLRequestContext`. (We will also add this to v4.1.0.)
For more information, see
GHSA-8r69-3cvp-wxc3
Copy file name to clipboardExpand all lines: CHANGELOG.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,6 +10,10 @@ The version headers in this history reflect the versions of Apollo Server itself
10
10
11
11
## vNEXT
12
12
13
+
## v3.11.0
14
+
- ⚠️ **SECURITY**: The cache control plugin no longer sets the `cache-control` HTTP response header if the operation is part of a batched HTTP request. Previously, it would set the header to a value describing the cache policy of only one of the operations in the request, which could lead to data being unintentionally cached by proxies or clients. This bug was introduced in v3.0.0 and this fix restores the behavior of Apollo Server 2. (In Apollo Server 4 (specifically, `@apollo/server@4.1.0` or newer), the features work properly together, setting the header based on the combined cache policy of all operations.) This could theoretically have led to data tagged as uncacheable being cached and potentially served to different users. More details are available at the [security advisory](https://github.com/apollographql/apollo-server/security/advisories/GHSA-8r69-3cvp-wxc3).
15
+
-`apollo-server-core`: New field `GraphQLRequestContext.requestIsBatched` available to plugins.
16
+
13
17
## v3.10.4
14
18
15
19
-`apollo-server-core`: Manage memory more efficiently in the usage reporting plugin by allowing large objects to be garbage collected more quickly. [PR #7106](https://github.com/apollographql/apollo-server/pull/7106)
0 commit comments