What is the expected HttpClient behavior when a traceparent header is manually added as a content header?

[nrcventura]

I encountered a problem recently where 2 traceparent headers were received by a service. The service sending the request was a .net application acting as a reverse proxy based on the design in https://auth0.com/blog/building-a-reverse-proxy-in-dot-net-core/ which copies incoming request headers to a new outgoing HttpRequestMessage as content headers instead of request headers. As a result both the System.Net.Http.DiagnosticsHandler and reverse proxy code add a traceparent header (with different values) to different collections which both get sent on the outgoing request, resulting in the downstream service seeing 2 traceparent headers.

If the reverse proxy code is updated to instead copy the incoming headers to the HttpRequestMessage request headers collection instead of the content headers headers collection, only 1 traceparent header is sent to the downstream service, and it's the one added by the reverse proxy code.

Is this the expected behavior? Should the HttpClient code be more defensive in this situation and just keep one of those headers? If so which header should be kept? If you keep the one added by the reverse proxy, you will lose information about the reverse proxy in the distributed trace, but it would be consistent with the behavior of the reverse proxy adding the header as a request header.