Issue explicitly forwarding Content-Type header with introspected federation API

[blegrosvoalte]

Bug description

When using the following code block to build header forwarding for a federated introspection, I'm seeing headers replaced with templates rather than values:

function buildHeaders(builder) {
    return builder
        .addClientRequestHeader('Content-Type', 'Content-Type')
        .addClientRequestHeader('Authorization', 'Authorization')
        .addClientRequestHeader('X-Custom-Header', 'X-Custom-Header');
}

My subgraph is receiving the following HTTP request headers (shown as JSON):

{"accept":"application/json","content-type":"{{ .request.headers.Content-Type }}","authorization":"{{ .request.headers.Authorization }}","x-custom-header":"{{ .request.headers.X-Custom-Header }}","user-agent":"axios/0.26.1","content-length":"1811","host":"localhost:4001","connection":"close"}

By removing the .addClientRequestHeader('Content-Type', 'Content-Type') line, I start to get header values forwarded correctly. This is an acceptable work around, I just wanted to pass along what I encountered.

How to reproduce

1. Use Wundergraph as an Apollo Federated gateway building header to forward as described in the description.
2. Call wunderctl up
3. Execute a request to Wundergraph
4. Observe the HTTP request sent to the subgraph's HTTP server (see example in bug description)

Expected behavior

Receive the specified forwarded header values provided in the HTTP request to the Wundernode in the subgraph.

WunderGraph information

wundergraph.server.ts

import { GraphQLObjectType, GraphQLSchema, GraphQLString } from 'graphql';
import { configureWunderGraphServer } from '@wundergraph/sdk';
import type { HooksConfig } from './generated/wundergraph.hooks';
import type { InternalClient } from './generated/wundergraph.internal.client';

export default configureWunderGraphServer<HooksConfig, InternalClient>(() => ({
	hooks: {
		queries: {},
		mutations: {}
	}
}));

wundergraph.operations.ts

import { configureWunderGraphOperations } from '@wundergraph/sdk';
import type { OperationsConfiguration } from './generated/wundergraph.operations';

export default configureWunderGraphOperations<OperationsConfiguration>({
	operations: {
		defaultConfig: {
			authentication: {
				required: false,
			},
		},
		queries: (config) => ({
			...config,
			caching: {
				enable: false,
				staleWhileRevalidate: 60,
				maxAge: 60,
				public: true,
			},
			liveQuery: {
				enable: false
			},
		}),
		mutations: (config) => ({
			...config,
		}),
		subscriptions: (config) => ({
			...config,
		}),
		custom: {},
	},
});

wundegraph.config.ts:

function buildHeaders(builder) {
    return builder
        .addClientRequestHeader('Content-Type', 'Content-Type')
        .addClientRequestHeader('Authorization', 'Authorization')
        .addClientRequestHeader('X-Custom-Header', 'X-Custom-Header');
}

const upstreams = [
    {
        url: 'http://localhost:4001/graphql',
        headers: buildHeaders
    }
];

const federatedApi = introspect.federation({
    upstreams
});

const myApplication = new Application({
    name: 'my-federated-gateway',
    apis: [federatedApi]
});

configureWunderGraphApplication({
    application: myApplication,
    server,
    operations,
    cors: {
        ...cors.allowAll,
        allowedOrigins: ['https://studio.apollographql.com']
    },
    security: {
        enableGraphQLEndpoint: true,
    },
});

Environment & setup

• OS: OSX
• Go version: Default shipped with wunderctl
• Database: None
• Node.js version: 16.x

WunderCtl Version

Version: 0.99.3
Commit: 2be71e21894cf0982bfcbf8d68c066e273d26a1f
Date: 2022-08-25T20:12:53Z
BuiltBy: ci

[jensneuse]

Just to clarify, when you use .addClientRequestHeader('Content-Type', 'Content-Type'), it shows the error as described above. When you remove this line and only keep .addClientRequestHeader('Authorization', 'Authorization') .addClientRequestHeader('X-Custom-Header', 'X-Custom-Header'); the other headers work fine? Or does it never work when you use the builder?

[blegrosvoalte]

@jensneuse That is correct. The builder works with the removal of the call to the builder to forward the header Content-Type.

[jensneuse]

@jensneuse That is correct. The builder works with the removal of the call to the builder to forward the header Content-Type.

I understand. Stupid question, why do you want to forward the Content-Type from the client? The gateway will send the federated Operations, so it will "own" the requests. All requests should be Content-Type application/json. What's a reason you'd like to override this?

[blegrosvoalte]

@jensneuse Just something I tried to start. It produced an error and I couldn't run the Wundernode, so I removed it and things worked. When I dug into the issue, I noticed the described behavior, so I thought it'd be helpful to report. We had also played around with the idea of changing the content-type to application/graphql which motivated the try, but we've decided not to go that route.

No worries if this is something y'all want to reject, just wanted to pass it along.

[jensneuse]

Yeah, I appreciate you've opened the issue. I'm not against allowing to pass Content-Type, it's just weird that it has these side effects. We'll definitely look into it.

[jensneuse]

@spetrunin I think this is important input for your current task.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.