Adding a toggle for HTTP client spans to display URI/resource path name

[rohanm-1]

Is your feature request related to a problem? Please describe.

When using the OTEL Java agent, HTTP client spans default to very low-cardinality names such as HTTP GET. While this avoids metric explosion, it makes traces less informative when debugging or when migrating from agents like Datadog that include the request path in span names.

For example, an HTTP request: GET /users/123/orders/456

currently produces a span named: HTTP GET

This loses important context about which resource was called.

Describe the solution you'd like

Introduce a configurable toggle to include URI/resource path information in HTTP client span names, with simple templating/truncation options.

Default behavior (unchanged): HTTP GET

With toggle enabled: HTTP GET /users/?/orders/?

This would:

• Preserve OTEL’s low-cardinality defaults OOTB
• Provide an optional path-based naming mode for users who need more informative spans (e.g. during migrations or debugging).

Describe alternatives you've considered

• Using an OTEL Collector transform processor, but in some environments (e.g. managed collectors) this isn’t feasible.
• Attempting to use OkHttp directly for higher-cardinality span names, but it doesn’t work out-of-the-box.

Additional context

If there is other advice on solving my issue that already exists please let me know, but I think this would be a good feature to add and would be a great learning experience for me

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[jhayes2-chwy]

After looking through the instrumentations currently support the experimental url.template-driven behavior, the list seems pretty short. Would it make sense to instead contribute updates to the HTTP Clients we use (OkHttp, HttpUrlConnection, etc.) to add support for url.template?

[rohanm-1]

Yes, I think that would be a great idea. Should I start implementation of these changes for those 2 http clients? Are there other clients you would recommend adding support for url.template?