opentelemetry-java icon indicating copy to clipboard operation
opentelemetry-java copied to clipboard

OkHttpHttpSender should support COMPATIBLE_TLS connectionSpec

Open jameyg42 opened this issue 5 months ago • 3 comments

Is your feature request related to a problem? Please describe. The OkHttp based exporter can only export to https:// endpoints that meet the requirements of the OkHttp MODERN_TLS ConnectionSpec.

Describe the solution you'd like the OkHttpHttpSender should support the COMPATIBLE_TLS ConnectionSpec (possibly via a config switch)

Describe alternatives you've considered A custom ExporterSender, but hits on #6718

Additional context Certain WebSphere 8.x systems (java 1.8) running on AIX platforms (for example) cannot export to https:// endpoints. The J9 1.8 JVMs cannot satisfy the requirements of OkHttp MODERN_TLS and there is no available otel-collector for AIX to handle a http://localhost type setup.

jameyg42 avatar Aug 15 '25 02:08 jameyg42

there is no available otel-collector for AIX to handle a http://localhost/ type setup.

I don't understand. You can definitely run the collector in a way that its accessible on http.

meet the requirements of the OkHttp MODERN_TLS ConnectionSpec.

I'm not familiar with this. Can you link to some documentation? Alternatively, maybe open a draft PR sketching out the rough idea for what would be required in OkHttpHttpSender.

jack-berg avatar Oct 23 '25 14:10 jack-berg

sorry for the confusion - in my example, i just meant that the otel-collector itself (or really anything golang) doesn't currently run on AIX, so the typical apm-agent --> http://localhost:4318 --> final-destination setup can't be done on that platform https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/19195

company rules prevent me from submitting a PR, but relaxing OkHttp TLS (which is likely needed to support many Java 1.7 distro's too) would be something along the line of adding

OkHttpClient.Builder      .......
   .connectionSpecs(singletonList(okhttp3.ConnectionSpec.COMPATIBLE_TLS))

to OkHttpHttpSender (and maybe OkHttpGrpcSender too) https://square.github.io/okhttp/security/tls_configuration_history/

jameyg42 avatar Oct 29 '25 14:10 jameyg42

As you're surely seen, we have a sender abstraction that allows us to have different HTTP / gRPC client implementations backing OTLP exporters.

This means we need to expose a OTLP exporter configuration API which is implementation-agnostic. I.e. we can't expose okhttp's ConnectionSpec in builders like OtlpHttpSpanExporterBuilder.

I haven't dived deep into the internals of okhttp to see what ConnectionSpec actually does, but I wonder if you can accomplish the same by customizing the SSL context: https://github.com/open-telemetry/opentelemetry-java/blob/main/exporters/otlp/all/src/main/java/io/opentelemetry/exporter/otlp/http/trace/OtlpHttpSpanExporterBuilder.java#L162-L172

If not, what might a generic configuration API look like that allows you to accomplish the same thing? And as we need to support multiple senders, what's the JDK 11+ HttpClient analog of okhttp's ConnectionSpec?

jack-berg avatar Nov 07 '25 22:11 jack-berg