Is your feature request related to a problem? Please describe.
As it stands, the way we choose to convert and/or encode headers varies substantially by language. See this AI-generated table:
| SDK |
Converter applied to headers? |
Codec applied to headers? |
| Go |
No — headers are written as raw Payload |
Partial — only via opt-in client-side gRPC interceptor; not on worker activation path |
| Java |
No — ContextPropagator returns Map<String, Payload> |
No — codec does not cover headers |
| Python |
No — interceptors set Mapping[str, Payload] |
Optional via HeaderCodecBehavior; default is NO_CODEC |
| TypeScript |
No — headers are Record<string, Payload> |
No — headers are skipped symmetrically |
| .NET |
No — interceptor inputs use IDictionary<string, Payload> |
Yes — broad codec coverage |
| Ruby |
Yes — headers pass through converter |
Yes — combined data converter includes codec |
| PHP |
Yes — values pass through converter |
No SDK codec class; codec handled externally |
Describe the solution you'd like
All SDKs should be capable of the same, normalized behavior. My inclination would be that this is to convert and encode all user-set headers (there may be some SDK set headers that would use the standard data converter).
Obviously, for backwards compatibility reasons, this behavior would need to be opt-in where it varies from the existing implementation. We might consider other options here, like continuing to be able to successfully decode existing headers while writing new headers under the new scheme, using SDK flags.
Additional context
This came up as part of the encryption verification project
Per-SDK Tickets
Is your feature request related to a problem? Please describe.
As it stands, the way we choose to convert and/or encode headers varies substantially by language. See this AI-generated table:
PayloadContextPropagatorreturnsMap<String, Payload>Mapping[str, Payload]HeaderCodecBehavior; default isNO_CODECRecord<string, Payload>IDictionary<string, Payload>Describe the solution you'd like
All SDKs should be capable of the same, normalized behavior. My inclination would be that this is to convert and encode all user-set headers (there may be some SDK set headers that would use the standard data converter).
Obviously, for backwards compatibility reasons, this behavior would need to be opt-in where it varies from the existing implementation. We might consider other options here, like continuing to be able to successfully decode existing headers while writing new headers under the new scheme, using SDK flags.
Additional context
This came up as part of the encryption verification project
Per-SDK Tickets