Add OTEL semantic conventions tags to HttpClient activity

[JamesNK]

ASP.NET Core has added OTEL semantic convention tags to the hosting activity.

PR: dotnet/aspnetcore#64851
Issue: dotnet/aspnetcore#52439

HttpClient should consider doing the same thing for the http out activity. See conventions here: https://opentelemetry.io/docs/specs/semconv/http/http-spans/#http-client-span

Benefits:

• Mirrors ASP.NET Core improvements
• Users of ActivitySourceListener sample callback can use creation tags to make sampling decision
• Reduce user requirement to use dotnet-opentelemetry-contrib

[dotnet-policy-service]

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

[martincostello]

I'd be happy to pick this up if no one's already assigned.

[ManickaP]

Sure, we'll gladly accept any help here 😄

[martincostello]

As far as I can tell from looking into this and comparing to v1.40.0 of the semantic conventions, the only required part that isn't implemented is this from footnote [1] for http.request.method:

If the HTTP instrumentation could end up converting valid HTTP request methods to _OTHER, then it MUST provide a way to override the list of known HTTP methods. If this override is done via environment variable, then the environment variable MUST be named OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS and support a comma-separated list of case-sensitive known HTTP methods.

This list MUST be a full override of the default known methods, it is not a list of known methods in addition to the defaults.

This would cover the case where the instrumentation doesn't support a specific HTTP method yet that the user wants to be included with instrumentation (e.g. if a user had wanted to use QUERY in a .NET 9 application before it had been added in .NET 10 by #115934).

Is that a change that's actually wanted here in the HttpClient instrumentation (not withstanding the fact it's a MUST) considering it requires reading an OTEL_ prefixed environment variable (as opposed to a DOTNET_ one) as there doesn't seem to be any prior art for that.

---

I assume that the opt-in parts aren't wanted (e.g. url.scheme and user_agent.original)?

If they are, then some sort of public API will be needed to be able to configure the ability to opt-in to them (or just some named environment variables and/or AppContext switches)

[ManickaP]

I gave it a quick look as well and it does not seem like there is anything required that we should add at the moment.

WRT OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS, I personally would not add it atm. We cover all the existing methods so I don't think there's an actual need for it now. And same for the Opt-In attributes.
If some customers / users come and request any of these, we can always reconsider and add it.

[martincostello]

If that's the case, then I guess this can be closed.

There's a commit referenced on this issue with possible changes to implement that if it's needed in the future.

[ManickaP]

Thank you for looking into this! I'm closing this then.