HTTP client metrics: url.scheme should be opt-in, server.port should be required

[lmolkova]

Description

OTel HTTP semconv made the last-minute change open-telemetry/semantic-conventions#459 before stability and now HTTP client metrics are not fully aligned with the spec (sorry).

Even though it's a pretty minor difference it'd be nice to align with the OTel spec at some point.

Reproduction Steps

N/A

Expected behavior

• url.scheme is now opt-in, so should be set when explicitly enabled (or not set at all)
• server.port should be set even when it has a default value

Actual behavior

scheme is always set, port is set when not default.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/Metrics/MetricsHandler.cs

Lines 192 to 198 in 33d7f98

	tags.Add("url.scheme", requestUri.Scheme);
	tags.Add("server.address", requestUri.Host);
	// Add port tag when not the default value for the current scheme
	if (!requestUri.IsDefaultPort)
	{
	tags.Add("server.port", requestUri.Port);
	}

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

OTel HTTP semconv made the last-minute change open-telemetry/semantic-conventions#459 before stability and now HTTP client metrics are not fully aligned with the spec (sorry).

Even though it's a pretty minor difference it'd be nice to align with the OTel spec at some point.

Reproduction Steps

N/A

Expected behavior

• url.scheme is now opt-in, so should be set when explicitly enabled (or not set at all)
• server.port should be set even when it has a default value

Actual behavior

scheme is always set, port is set when not default.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/Metrics/MetricsHandler.cs

Lines 192 to 198 in 33d7f98

	tags.Add("url.scheme", requestUri.Scheme);
	tags.Add("server.address", requestUri.Host);
	// Add port tag when not the default value for the current scheme
	if (!requestUri.IsDefaultPort)
	{
	tags.Add("server.port", requestUri.Port);
	}

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	lmolkova
Assignees:	-
Labels:	area-System.Net.Http, untriaged
Milestone:	-

[antonfirsov]

The current state (having a redundant scheme tag, not reporting default ports) doesn't actively hurt users from a practical POV. Given it's such a minor aspect, I wonder if maintaining maximum standard-compatibility is worth the burden of a breaking change where we may need to implement a compatibility switch, adding complexity to the code. @noahfalk what's your take on this?

[antonfirsov]

Triage: adding this to 9.0 for decision making, and potential fixing (see comment above).

[antonfirsov]

Related: #103302. Opt-in attributes likely need an API addition. Punting this to .NET 10.