[bug] Incompatibility between OTEL BaggagePropagator and .NET W3C Baggage Propagator

[gcannata2]

Package

OpenTelemetry

Package Version

Package Name	Version
OpenTelemetry.Api	1.14.0
OpenTelemetry	1.14.0

Runtime Version

net8.0

Description

Problem Description

With the latest upgrade to OpenTelemetry 1.14.0 and System.Diagnostics.DiagnosticSource 10.0.0, we've encountered a backward incompatibility issue with baggage propagation.

Background

In version 10.0, .NET definitively abandoned the Legacy propagator (which used the Correlation-Context header) and switched by default to the W3C Baggage standard (spec), which specifies:

• The header name is baggage
• Key-value pairs and = can be separated by optional whitespace (OWS)

In our service chain, we rely on .NET Activity Baggage because we cannot guarantee that all services are instrumented with OTEL.

Issue

When we updated to OTEL 1.14.0, baggage propagation broke. Here's what happens:

1. .NET propagates baggage using the baggage header with key-values separated by = and spaces (e.g., key = value)
2. OTEL BaggagePropagator reads this header but expects key-values to be separated by = without spaces (as per OTEL spec), so it parses the spaces as part of keys and values
3. HttpClient instrumented by OTEL injects baggage using the OTEL BaggagePropagator, which URL-encodes the baggage (via WebUtility.UrlEncode)
4. Downstream .NET services receive a baggage header with keys and values like +key+=+value+ instead of key=value

Question

Is this behavior intentional? The W3C Baggage specification allows optional whitespace around =, so it seems the OTEL BaggagePropagator should be compatible with this.

Workaround

We've worked around this by removing the OTEL BaggagePropagator from the Propagators collection, but it seems the OTEL BaggagePropagator should handle W3C-compliant baggage headers that include spaces.

Thanks a lot!

Steps to Reproduce

Set up a Service (A) that adds some keys and values to current activity using System.Diagnostics:

 Activity.Current?.AddBaggage("correlationId", "12345");
 Activity.Current?.AddBaggage("userId", "user-abc");

either do not instrument this service with OTEL or propagate the context in a way that is not handled by OTEL (in our case, it is a YARP reverse proxy).

Service (A) calls a Service (B) which is instrumented with OTEL
Service (B) calls - via HttpClient - a Service (C)

Expected Result

Service (C) should be able to correctly read the keys from the baggage.

var correlationId = Activity.Current?.GetBaggageItem("correlationId");

Actual Result

Service (C) receive keys and values "urlencoded"

var correlationId = Activity.Current?.GetBaggageItem("+correlationId+");

Additional Context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[martincostello]

The change was intentional insofar that .NET 10 made a breaking change behavioural change to use the W3 propagator by default, which we then implicitly use: Default trace context propagator updated to W3C standard

We then explicitly opt-out of this in some of our own tests, as documented in the breaking change notes:

opentelemetry-dotnet/test/OpenTelemetry.Instrumentation.W3cTraceContext.Tests/W3CTraceContextTests.cs

Lines 27 to 31 in aa78a93

	static W3CTraceContextTests()
	{
	// See https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/10.0/default-trace-context-propagator
	DistributedContextPropagator.Current = DistributedContextPropagator.CreatePreW3CPropagator();
	}

If you need the previous behaviour, you should be able to opt-out in the same way.

If you don't want to opt-out, but there's a bug in the default W3C implementation, then that should be logged as an issue in the dotnet/runtime repository.

[gcannata2]

Thank you @martincostello.
I think adopting the W3C standard would be beneficial, as legacy components can remain backward compatible by reading both the baggage and Correlation-Context headers.

Since it's often not feasible to control or update an entire service chain at once, being as lenient as possible with header parsing is crucial. Converging toward the W3C format would help ensure that baggage propagates correctly across heterogeneous environments.

Currently, when an OTEL-instrumented service receives a baggage header in W3C-compliant format (with optional whitespace), it misinterprets the spaces as part of the key/value data and breaks the propagation chain for downstream services.

My suggestion is to add support for optional whitespace around = as defined in the W3C specification. This would allow OTEL baggage propagation to coexist seamlessly with W3C-compliant baggage without requiring all services in the chain to use OTEL instrumentation.

[martincostello]

This might be a duplicate of #5210 and/or #5260.