Populate name field in exported span with http.target attribute

[FieteO]

First of all, thanks for providing this library to support tracing in web apps! I am using it in conjunction with Jaeger for end to end traces.
This works great, but I would have one improvement for the exported spans.

The picture above shows an example trace in the jaeger ui starting from the web app. The ui shows the names of the individual spans
in the Service & Operations pane in the center left of the image.
For the web app, the span name is displayed as GET, while for traces from other (spring-boot) apps, the endpoint url (i.e http get /customers/{customerId}) is used.
Looking at the json response in jaeger reveals that the field is called operationName that determines the name.

Now, when looking at the request of the span exporter, the field that would correspond to this is likely the name field:

Now my question: Is it possible to configure the exporter to use for instance the tags.http.target attribute instead of the http method?
If not, could it be implemented?

[jufab]

Hi, @FieteO
OpenTelemetry's semantic convention for client-type spans is pretty clear on the subject. It should only be of type method, unless we are able to determine the url.template (which is not the case for most calls). The case of Spring Boot is different because it is server-type span.
For more information, I invite you to read this https://github.com/open-telemetry/semantic-conventions/blob/main/docs/http/http-spans.md#name

[FieteO]

Ah, I think I see what you mean. The spec is saying: "HTTP span names SHOULD be {method} {target}".
{method} is what is currently exclusively being used by this library (http methods like GET or POST).

While {target} should be
- http.route for HTTP Server spans
- url.template for HTTP Client spans if enabled and available (Experimental)
- Other value MAY be provided through custom hooks at span start time or later.

Here, the client case applies and thus a url.template should be added as a {target} if it is available.
My change is adding a url.path (i.e /customers/mycustomer), while a template would be /customers/{customerId}.
And the latter is (without further changes?) not readily available.

Even though this is against the spec, could we perhaps hide this implementation behind a configuration?
Because it would still provide benefit to me to use the url.path and I can imagine that having the proper url.template is quite impossible with the interceptor approach that is taken, isn't it?

[jufab]

Yes, that is indeed the problem, and you have forgotten this sentence: The instrumentation MUST NOT use the URI path as the default {target}.
It is therefore difficult for me to accept this change.
However, I understand your issue and the one with Jaeger, but despite all that, this doesn't seem possible at the moment.