opentelemetry-http: fix url extraction #3274
Conversation
Motivation: Our url extraction is wrong in that it doesn't consider possible absolute-form request targets. We also don't allow users to set a host and port in the common case that it's using origin-form request targets and we can't extract a host name or port. Modifications: Fix the extraction and make it possible to provide a host and port.
bryce-anderson
changed the title
...y-http/src/main/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpRequesterFilter.java
Outdated
Show resolved
Hide resolved
...tp/src/test/java/io/servicetalk/opentelemetry/http/OpenTelemetryHttpRequesterFilterTest.java
Outdated
Show resolved
Hide resolved
| return null; | ||
| } | ||
| String scheme = request.scheme(); | ||
| if (scheme == null) { | ||
| scheme = HTTP_SCHEME; | ||
| scheme = effectiveHostAndPort.port() == 443 ? HTTPS_SCHEME : HTTP_SCHEME; |
There was a problem hiding this comment.
Just a note for anyone else looking at the PR: this is best effort. At client level, we don't know if the actually connection will be secure or not and therefore can not reliably detect scheme other than relying on standard port convention.
To make it work correctly, we may consider other options in the future. Some ideas are:
- Exposing client configuration for filters
- Using connection-level filter to attach
schemeattribute to the current span after connection is selected
| sb.append(requestTarget); | ||
| return sb.toString(); | ||
| String authoritySeparator = requestTarget.startsWith("/") ? "" : "/"; | ||
| return scheme + "://" + authority + authoritySeparator + requestTarget; |
There was a problem hiding this comment.
Could you remind me what we decided on our last discussion: should we use path() or requestTarget()?
There was a problem hiding this comment.
We decided to use path but I didn't change that behavior here: I think it's worth a separate PR and a bit more discussion since it will diverge from what OTEL specifies.
There was a problem hiding this comment.
I see io.opentelemetry.instrumentation.api.semconv.http.HttpClientAttributesExtractor has stripSensitiveData method, but it's private. They simply hardcoded some well-known parameters, like AWSAccessKeyId or Signature, without a way to extend it 😕
Motivation:
Our url extraction is wrong in that it doesn't consider possible absolute-form request targets.
Modifications:
Fix the extraction.