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.
Apollo Server 4 has the same overall behavior (though the details of the
particular objects in question have changed a bit).
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.
To fix this, we are making a change to the
`GraphQLRequestContext.response` object as seen by plugins. This
object's `http` field is now shared across all operations in a batched
request, instead of being specific to the individual operation. This
means that any changes to headers (or HTTP status code) in plugins
processing one operation are immediately visible to plugins processing
another operation, and so they can properly merge header values.
**This change is technically backwards-incompatible.** However, as this
is a relatively subtle change and as Apollo Server 4 is very new and its
adoption is relatively low (we haven't even formally announced AS4 on
our blog yet), we feel comfortable making this change in a minor version
instead of in a new major version.
The cache control plugin is changed to merge `cache-control` response
headers across multiple operations in a batched request. Note that if
the `cache-control` header is ever set to any value that could not be
written by the cache control plugin, the plugin will refuse to update it
further so as not to lose information. (It is best to only set the
header from one place, and to disable the cache control plugin's
header-writing feature with `calculateHttpHeaders: false` if you want to
write the header from elsewhere.)
Additionally, a new `requestIsBatched: boolean` field is added to
`GraphQLRequestContext`. This isn't read by anything in this PR.
However, we will backport this field to Apollo Server 3, and use it to
disable cache-control header writing for batched requests. (Backporting
the full solution to AS3 would be challenging because the relevant data
structures are more complex, and making a backwards-incompatible change
to an older version like AS3 is more problematic.)
For more information, see
GHSA-8r69-3cvp-wxc3
The `cache-control` HTTP response header set by the cache control plugin now properly reflects the cache policy of all operations in a batched HTTP request. (If you write the `cache-control` response header via a different mechanism to a format that the plugin would not produce, the plugin no longer writes the header.) For more information, see [advisory GHSA-8r69-3cvp-wxc3](https://github.com/apollographql/apollo-server/security/advisories/GHSA-8r69-3cvp-wxc3).
Plugins processing multiple operations in a batched HTTP request now have a shared `requestContext.request.http` object. Changes to HTTP response headers and HTTP status code made by plugins operating on one operation can be immediately seen by plugins operating on other operations in the same HTTP request.
0 commit comments