Repository navigation
EndpointUtil.validateEndpoint not handling all valid DNS host names #8745
Description
Describe the bug
the recent check to validate hostname in EndpointUtils.validateEndpoint() is hitting
https://bugs.openjdk.org/browse/JDK-8188305
that is, URI.getHost() returns null for hostnames that are valid according to modern DNS standards (in my particular case, hostnames w/ a segment that starts with a number).
Steps to reproduce
set otel.exporter.etlp.endpoint to http://otlp.1234-k8s-namespace:4318 (or any other value that triggers the URI.getHost() bug)
What did you expect to see?
normal agent startup
What did you see instead?
io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder - Error encountered during autoconfiguration. Closing partially configured components.
io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: Unexpected configuration error
at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.buildImpl(AutoConfiguredOpenTelemetrySdkBuilder.java:510)
at io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdkBuilder.build(AutoConfiguredOpenTelemetrySdkBuilder.java:431)
...
Caused by: java.lang.IllegalArgumentException: Invalid endpoint, must start with http:// or https://: http://otlp-collector.14014-mosaik:4318/v1/metrics
at io.opentelemetry.exporter.internal.EndpointUtil.validateEndpoint(EndpointUtil.java:34)
at io.opentelemetry.exporter.otlp.internal.HttpExporterBuilder.setEndpoint(HttpExporterBuilder.java:94)
at io.opentelemetry.exporter.otlp.http.metrics.OtlpHttpMetricExporterBuilder.setEndpoint(OtlpHttpMetricExporterBuilder.java:127)
What version and what artifacts are you using?
edot-java:1.12.0 (otel-instrumentation:2.30.0; sdk: 1.64.0)
possible workaround
in my particular case, because this was a hostname from a k8s namespace that follows a number-prefix naming convention, I was able to get around the java bug simply by using the service FQDN (otlp.1234-k8s-namespace.svc.cluster.local)
Activity
jack-berg commentedon Sep 9, 2026
See #8746 (comment)
Being more accommodating with hosts works for the default OkHttp senders, but not for JdkHttpSender or UpstreamGrpcSenderProvider.
hitkall commentedon Sep 15, 2026
Hi! I looked into fixing the two remaining senders after #8746. It turns out the gRPC managed-channel sender can't be fixed on our side either, because grpc-java has the same JDK bug.
I tested it against grpc-java 1.84 with
grpc-netty-shaded:ManagedChannelBuilder.forAddress(null, -1)(whatUpstreamGrpcSenderProviderpasses today)NullPointerException: targetforAddress("otlp.1234-k8s-namespace", 4317)IllegalArgumentException: Invalid host or portforTarget("otlp.1234-k8s-namespace:4317")IllegalArgumentException: Invalid DNS nameforTarget("dns:///otlp.1234-k8s-namespace:4317")IllegalArgumentException: Invalid DNS nameforTarget("localhost:4317")GrpcUtil.authorityFromHostAndPortandDnsNameResolverboth check the host withjava.net.URI, so they hit JDK-8188305 too. Getting the host fromjava.net.URLon our side doesn't help. The only workaround I can see is resolving DNS ourselves and passing a fixed address, and that would break re-resolution and load balancing.So both
JdkHttpSenderandUpstreamGrpcSenderProviderare blocked by code outside this repo. What I'd propose here:URI.getHost()isnull, they'd throw an error saying the hostname isn't supported by that sender, and suggest the default OkHttp sender or a fully qualified name (e.g.*.svc.cluster.local). Today users getunsupported URIon first export orNullPointerException: target, which don't point to the cause.@jack-berg does (1) sound reasonable? I'm happy to send the PR, and to open the grpc-java issue.
jack-berg commentedon Sep 16, 2026
Yes (1) sounds reasonable to me. Ideally we would fail fast at the time
setEndpointis called, but we don't know which sender will be resolved yet so its not practical. Checking at sender construction time still gives a fail fast error at initialization time, which is better than waiting for hte first export to be called.hitkall commentedon Sep 24, 2026
Opened #8856 · Fail fast in JDK and grpc-java… for (1): both senders now throw a clear IllegalArgumentException when they're created if URI.getHost() is null. The gRPC check only applies to the fallback channel, not to an explicitly set ManagedChannel.
Also reported the grpc-java side upstream: grpc/grpc-java#13075. Once that's fixed, the managed-channel sender check can be relaxed.