Fix OtlpExporterOptionsExtensions.GetHeaders incorrectly throwing for comma in header value

[tobias-tengler]

Fixes #6510

Changes

Updates OtlpExporterOptionsExtensions.GetHeaders to no longer throw for commas inside of header values.
Previously a valid header value like VL-Stream-Fields=service.name,service.environment would've thrown, since the comma would've been incorrectly interpreted as a delimiter to another header pair - now it's properly parsed.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: tobias-tengler / name: Tobias Tengler (226edef, f0f44e6, 4e1b471)

[matt-hensley]

likely able to avoid the additional string allocations and only use spans for the new parsing logic

[tobias-tengler]

How do you mean? I'm already using Span for the parsing, but there's no way around allocating a string for the key and value at some point.

[matt-hensley]

initial read looked like there were multiple ToString calls. looks reasonable to push those calls as late as possible

[tobias-tengler]

Do you have a concrete idea of how to do so? I'm not even sure if performance improvements in this part of the code matter that much. This isn't even on any hot path right?

[tebeco]

I feel like the headers shouldn't be a string at all TBH.
the day we'll need to send a Base64 value that's being padded with = what will happen ?

If we're sending headerS (multiples), it sounds like this should be a List<KeyValuePair<string, string>> or something similar @matt-hensley .
Just like Resource/Attribute

I'm not mentionning Dictionary<string, string> because i'm not sure it's good or not to deal with dup / de-dup in headers, I don't know the specs enough

Else it will turn into another footgun TBH

[tobias-tengler]

@tebeco I like the idea.
Just want to add that we for example define the headers as an environment variable that we pass to the string option, since we use different exporters for different environments.
If the API would change to just List<KeyValuePair<string, string>> we would have to do this parsing in user-land.

Which could be fine. It would just add churn for everyone currently using the string option.

[tebeco]

the other thing i haven't looked at all is performance
i don't know the impact of switching from string to List

what i remember is in aspnetcore they use a special StringValues value type because generally a header often only have one value

i have no knowledge of the OTEL specifics here

im just adding it here in case it rings a bell for someone

i hope it doesn't explode the scope of that evol'

[tebeco]

@tebeco I like the idea.

Just want to add that we for example define the headers as an environment variable that we pass to the string option, since we use different exporters for different environments.

If the API would change to just List<KeyValuePair<string, string>> we would have to do this parsing in user-land.

Which could be fine. It would just add churn for everyone currently using the string option.

yeah, i feel the pain, dealing with env var and array is generally not fun

unless you split env var to multiple aggregate yourself and then map it
similar to what dotnet config does for array (but that's not pretty)

i don't think there's such thing as escape in env var
and its also OS specific i assume

[tobias-tengler]

@tebeco @matt-hensley what would you recommend as next steps? Should I implement the headers as List<KeyValuePair<string, string>> or how should we proceed here.
This is currently blocking me and I haven't been able to find a workaround.

[tebeco]

this is something one of the maintainers of this repository should properly plan ahead to avoid a later API issue

I'm just an outsider here with the similar issue, but from the code itself, not from env var

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[rajkumar-rangaraj]

this is something one of the maintainers of this repository should properly plan ahead to avoid a later API issue

I'm just an outsider here with the similar issue, but from the code itself, not from env var

Agreed, this is something that warrants proper planning from the maintainers. We've been focused on other high priority items in the repo and will take a closer look at this after we complete the .NET 10 tasks.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[tebeco]

can someone check how to remove the auto stale bot as well as the comment spammed above ?

this feature is still missing and blocking vendor requiring vendor that needs multi header value.
this can be useful when integrated the solution with external partners

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[github-actions]

This PR was marked stale due to lack of activity and will be closed in 7 days. Commenting or pushing will instruct the bot to automatically remove the label. This bot runs once per day.

[tobias-tengler]

this is something one of the maintainers of this repository should properly plan ahead to avoid a later API issue
I'm just an outsider here with the similar issue, but from the code itself, not from env var

Agreed, this is something that warrants proper planning from the maintainers. We've been focused on other high priority items in the repo and will take a closer look at this after we complete the .NET 10 tasks.

@rajkumar-rangaraj Seeing that a version with support for .NET 10 has been released, do you think the maintainers could have a look at this in the near future?

[tebeco]

this is indeed an important topic for vendor integration

[rajkumar-rangaraj]

There is a regression with values that contain = characters.

Failing example:

Authorization=Bearer token=abc,key2=value2

The current algorithm:

• nextEqualIndex = 13 → key = Authorization
• headersSpan = "Bearer token=abc,key2=value2"
• headersSpan.IndexOf('=') → finds the = inside the token (index 12)
• potentialValue = "Bearer token", lastComma = -1
• Throws ArgumentException

The previous implementation worked because it split by comma first, and then treated everything after the first = as part of the value.

This impacts real headers such as:

• Authorization=Bearer token=abc
• Base64-padded values: X-Custom=dGVzdA==
• Query-string style values: X-Redirect=https://example.com?foo=bar

Recommended test cases:

[InlineData("Authorization=Bearer token=abc,key2=value2", "Authorization=Bearer token=abc", "key2=value2")]
[InlineData("X-Custom=dGVzdA==,key2=value2", "X-Custom=dGVzdA==", "key2=value2")]
[InlineData("X-Redirect=https://example.com?foo=bar,key2=value2", "X-Redirect=https://example.com?foo=bar", "key2=value2")]

[tobias-tengler]

@rajkumar-rangaraj good catch. I can come up with a fix and update my PR, if we want to keep this string-based API. Previous comments raised the issue that if we touch this part we should probably align to a key-value-pair based API like it's done in other parts. Either is fine with me, I just don't want to waste time on something we might discard again before merging.

[rajkumar-rangaraj]

@rajkumar-rangaraj good catch. I can come up with a fix and update my PR, if we want to keep this string-based API. Previous comments raised the issue that if we touch this part we should probably align to a key-value-pair based API like it's done in other parts. Either is fine with me, I just don't want to waste time on something we might discard again before merging.

Given this isn't in the hot path, the most pragmatic approach might be to keep it simpler. That said, it's good to apply performance/zero-allocation patterns.

[tebeco]

i don't want to disrupt but why a special treatment on "," or others

would this be naive to have another property that defines the delimiter and split on it ?

this assume that this delimiter is now the delimiters for headers

and is defaulted to ","

[rajkumar-rangaraj]

i don't want to disrupt but why a special treatment on "," or others

would this be naive to have another property that defines the delimiter and split on it ?

this assume that this delimiter is now the delimiters for headers

and is defaulted to ","

We follow a principle of minimizing the number of public APIs that perform similar tasks. Hence this is not an option.

[tebeco]

fair enough, this decision only weight into maintenance cost between a parser and all possible combinatory string including futures one (dealing with " ' ` or or \" or "" or nesting ...), versus just splitting on a const

I totally understand the decision made regarding the "api surface" in balance of all that 👍