fix: Change user-agent in OTLP Exporter to match spec

[cijothomas]

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md#user-agent

Changes default user-agent from "OTel OTLP Exporter Rust/version" to "OTel-OTLP-Exporter-Rust/version". Spec does not mandate this particular format, but the example given in the spec and some implementations (Java/.NET) follows this. Golang follows different format.

We could ask spec to clarify, but for now, I think its best to change to the ones shown in spec examples.

[Copilot]

Pull Request Overview

Updates the default User-Agent header format in the OTLP exporter to align with OpenTelemetry specification examples, changing from space-separated to hyphen-separated format.

• Changes User-Agent format from "OTel OTLP Exporter Rust/version" to "OTel-OTLP-Exporter-Rust/version"

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.5%. Comparing base (097dab9) to head (903fe24).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #3110   +/-   ##
=====================================
  Coverage   80.5%   80.5%           
=====================================
  Files        126     126           
  Lines      22218   22218           
=====================================
  Hits       17889   17889           
  Misses      4329    4329           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lalitb]

FYI - there is PR in specs to make user-agent field configurable - open-telemetry/opentelemetry-specification#4560

[cijothomas]

FYI - there is PR in specs to make user-agent field configurable - open-telemetry/opentelemetry-specification#4560

yes that is to append something to user-agent right, not outright replacement? replacement can be done today by passing extra header with the same name, to replace the existing one.

[lalitb]

yes that is to append something to user-agent right, not outright replacement?

yes

[utpilla]

replacement can be done today by passing extra header with the same name, to replace the existing one.

Are we validating the header values in such cases? If not, we should add some validation at least for length and character set.

https://medium.com/perimeterx/user-agent-based-attacks-are-a-low-key-risk-that-shouldnt-be-overlooked-1a5d487a1aa0

[cijothomas]

replacement can be done today by passing extra header with the same name, to replace the existing one.

Are we validating the header values in such cases? If not, we should add some validation at least for length and character set.

https://medium.com/perimeterx/user-agent-based-attacks-are-a-low-key-risk-that-shouldnt-be-overlooked-1a5d487a1aa0

No we are not doing validations on any additional headers users add. Should we be doing that? There isn't anything about this in the spec, so we have to come up with our own rules.

We can do some sanity check when headers are provided at build time. But users can add interceptors, and add/modify headers on each request - so we need to add validation here too after all user-interceptors are done. Even then users can still bring their own http client or gRPC channel, at which point we (OTel) has minimal control?

Anyway, this is better discussed in a separate issue.

[cijothomas]

replacement can be done today by passing extra header with the same name, to replace the existing one.

Are we validating the header values in such cases? If not, we should add some validation at least for length and character set.
https://medium.com/perimeterx/user-agent-based-attacks-are-a-low-key-risk-that-shouldnt-be-overlooked-1a5d487a1aa0

No we are not doing validations on any additional headers users add. Should we be doing that? There isn't anything about this in the spec, so we have to come up with our own rules.

We can do some sanity check when headers are provided at build time. But users can add interceptors, and add/modify headers on each request - so we need to add validation here too after all user-interceptors are done. Even then users can still bring their own http client or gRPC channel, at which point we (OTel) has minimal control?

Anyway, this is better discussed in a separate issue.

#3115 opened