Outbound header propagation about router HOT 4 CLOSED

My understanding of initial use cases is:

• As a router operator, I want to expose the header1 HTTP Response header returned from subgraphB to the requesting client as an HTTP Response header.
• As a router operator, I want to expose the header1 HTTP Response header from any subgraph to the requesting client as an HTTP Response header.
• As a router operator, I want to expose the header1 from all subgraphs to the requesting client as multiple HTTP Response headers (i.e., repeated) — e.g., consider headers like set-cookie.
• As a router operator, I want to reduce and expose the header1 HTTP Response header returned from any subgraphs to the client as a single HTTP Response header — e.g., like a Surrogate-Key header.

However, I (we?) don’t currently/yet have clarity into what the expectations are for subgraphs that are touched multiple times in a query plan’s execution (i.e., there are multiple FetchNodes to the same subgraph). For example, if subgraphB is called first, then called in a subsequent (tertiary+?) _entities fetch, but each returns a header1 HTTP Response header, when is this permitted? (Always?) What is the behavior? (First wins? Last wins?) The answer for the Surrogate-Key scenario seems more intuitive to me, while the others are perhaps a bit more blurry in my mind right now.

from router.

As a follow-up to the initial version, doing this declarative in the graph is appealing, but this could be a follow-up issue. Those scenarios are very similar, but the stories user perspective changes slightly:

• As a subgraph operator, I want to ask to expose the header1 HTTP Response header that I will return from my subgraph to the requesting client as an HTTP Response header.
• As a subgraph operator, I want my header to be interpolated with other header1 HTTP Response headers returned from other subgraphs to the client as a single response header — e.g., participating in a Surrogate-Key HTTP Response header scheme.

One could imagine that these could be done with core-directives in the subgraph. However, I'll note that there are governance needs here to cover a router operator's concern that arises in these scenarios, but that I'd claim that those governance concerns can be handled supergraph composer/processor rules. I'd claim that those are outside of the scope of the Router's concern, but might be:

• As a router operator, when subgraph operators are requesting to return HTTP headers to the client, I want to be able to control what can be returned.

from router.

Closed as part of #303. This should be possible now with the new header extension configuration stuff which is incoming!

from router.

You should add this in the documentation... there's only information on inbound header propagation.

from router.