Sending HTTP headers to subgraphs
Configure which headers the Apollo Router sends to which subgraphs
You can configure which HTTP headers the Apollo Router includes in its requests to each of your subgraphs. You can define per-subgraph header rules, along with rules that apply to all subgraphs.
You define header rules in your YAML configuration file, like so:
# ...other configuration...headers:all: # Header rules for all subgraphs- propagate:matching: ^upstream-header-.*- remove:named: "x-legacy-account-id"subgraphs:products: # Header rules for just the products subgraph- insert:name: "router-subgraph-name"value: "products"
The Apollo Router supports the following types of header rules:
Enables you to selectively pass along headers that were included in the client's request to the router.
You can specify which headers to propagate based on a matching regex pattern:
- propagate:matching: .*
Note: The Apollo Router never propagates so-called hop-by-hop headers (such as
Content-Length) when propagating by pattern.
Alternatively, you can provide a static string via the
named option. These
named configurations have additional flexibility, because they support the following options:
default: A value to set if no value was sent by the client
rename: Renames the header's key to the provided value
- propagate:named: "x-user-id"default: "abc123"rename: "account-id"
# Do not send this subgraph the "Cookie" header.- remove:named: "Cookie"- remove:# Remove headers that include the legacy 'x-' prefix.matching: ^x-.*$
Enables you to add custom headers to requests going to a specific subgraph. These headers are always static strings that originate in the router, instead of originating in the client.
- insert:name: "sent-from-our-apollo-router"value: "indeed"
Rules are applied in the order in which they are declared. For example:
headers:all:- remove:named: "test"- propagate:matching: .*
In this example, the header named test would be removed from the propagation list, but then immediately the propagate rule would match and ensure it was added back to the list. This is clearly undesirable. To do this correctly, ensure that the propagate rule is specified first in your configuration:
headers:all:- propagate:matching: .*- remove:named: "test"
This would result in adding all headers to the propagation list, then removing the header named "test", which is the desired outcome.
Here's a complete example showing all the possible configuration options in use:
headers:# Header rules for all subgraphsall:# Propagate matching headers- propagate:matching: ^upstream-header-.*# Propagate matching headers- propagate:named: "some-header"default: "default-value"rename: "destination-header"# Remove the "x-legacy-account-id" header- remove:named: "x-legacy-account-id"# Remove matching headers- remove:matching: ^x-deprecated-.*# Insert the 'my-company' header- insert:name: "my-company"value: "acme"# Subgraph-specific header rulessubgraphs:products:# Calls to the products subgraph have the "router-subgraph-name" header set to `products`.- insert:name: "router-subgraph-name"value: "products"accounts:# Calls to the accounts subgraph have the "router-subgraph-name" header set to `accounts`.- insert:name: "router-subgraph-name"value: "accounts"