OkHttpHttpSender should support COMPATIBLE_TLS connectionSpec
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.
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.
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/
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?