Don't capture http.scheme, http.host and http.target if already capturing http.url

[trask]

http.scheme, http.host and http.target are redundant if already capturing http.url.

While more telemetry is good, this redundancy doesn't seem worth the (small) additional performance and storage costs.

[anuraaga]

I guess my #3699 (comment) applies here too. I think we would want to make a call on if the performance matters at all, and if not then we should just remove one of those two versions from the HttpAttributes instrumentation API

[iNikem]

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/semantic-conventions.md#http-server claims that we don't set them :) And explains why :)

[anuraaga]

Yeah but it seems to be not really enforced, just an end result? I think of a few options

1. Populate as much of URL, scheme, host, target as possible, possibly by constructing, which I think is done by most implementations using Instrumenter API, perhaps not Tracer.

• Making sure instrumentation populates as much as possible was one of its design goals which resulted in this

2. Per instrumentation, decide to populate either URL or the triplet
3. Decide to always populate URL for client, triplet for server

• This could be modeled with the instrumentation API, I think we realized separately that splitting client an server can help writing instrumentation that only supports one of those modes

4. Just always populate URL and forget the triplet to avoid cognitive load of this sort of knob

3. seems OK if it's correct, I'm not 100% sure the assumption, especially on client side, is valid. If there isn't any consistent behavior, 4) for simplicity just seems OK as well.

[trask]

At least until we "resolve #3700"

oops 😂