Disabling `sendEnhancedClientAwareness` Still Sends Client Awareness Headers

[trevholliday]

Summary

Unexpected Behavior When Disabling Client Awareness:
Setting the sendEnhancedClientAwareness property to false on the RequestChainNetworkTransport does not prevent the headers apollographql-client-name and apollographql-client-version from being included in the request. This behavior contradicts the expectation that toggling this flag would completely disable these headers.

Opt-In Requirement for New Headers:
Any new headers that modify the request behavior or introduce additional metadata should follow an opt-in implementation pattern. By default, new headers should be disabled and require explicit user configuration

Version

1.23.0

Steps to reproduce the behavior

1. During initialization of the RequestChainNetworkTransport set sendEnhancedClientAwareness to false.
2. Requests still sending apollographql-client-name and apollographql-client-version

Logs

Anything else?

No response

[calvincestari]

Hi @trevholliday - I acknowledge that this is confusing but it is not a bug; this behaviour is by-design and documented on the method parameters; here on ApolloClient, here on RequestChainNetworkTransport, although it's missing completely on JSONRequest (I'll get that added).

Specifies whether client library metadata is sent in each request extensions key.

You'll notice that the wording used on the parameter documentation specifically mentions "request extensions key". This does not affect the request headers and those cannot be disabled in 1.x without writing custom code to build the request. It has always been this way in 1.x and I don't foresee it changing in any future 1.x version. Apollo iOS is the laggard here as the headers are configurable in the latest versions of both Apollo Client and Apollo Kotlin. The good news is that Apollo iOS 2.0 will provide far easier customization of those request headers.

I'm certain end-users do not care about this distinction, but the nuance here is the word "enhanced" which we use to distinguish between the existing Client Awareness feature of the Router and Apollo Server (controlled through request headers) and Enhanced Client Awareness which allows us to identify generic client types (controlled through request extensions key).

The long-term plan for this is to converge on a common transport mechanism for both (request headers or extensions key), controlled by a common configuration option. We're still a way off from that as there is a fair bit of Apollo backend infrastructure that needs to change to support that.

Apologies for the confusion.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.