LWP::Protocol::https loses Client-SSL-Version response metadata

Start with t/example.t and trace get_sslversion from LWP::Protocol::https through IO::Socket::SSL to the Java bridge's _get_sslversion implementation. Verify that the Java SSLSocket session protocol reaches Perl as the expected TLSvN.N or SSLvN value and that the same TLS-upgraded socket is used. Done means a deterministic local or mock regression test passes and t/example.t succeeds on both backends when network access is available.

Summary

LWP::Protocol::https v6.15 can complete an HTTPS request under PerlOnJava but fails to expose the negotiated TLS protocol version through the expected Client-SSL-Version response header.

CPAN evidence

• CPAN run: 20260918-141920-96054
• Distribution: LWP::Protocol::https v6.15
• System Perl: PASS — 4 files, 62 tests
• PerlOnJava: FAIL — 1/4 test programs, 1/6 reported subtests

The failing test is t/example.t. The HTTPS request to https://httpbin.org succeeds, and the other response metadata checks pass, but this assertion fails:

Failed test 'have header Client-SSL-Version'

The PerlOnJava run skips t/https_proxy.t because fork is unsupported; that skip is unrelated to the failure.

Expected behavior

After a successful HTTPS request, LWP::Protocol::https should expose a negotiated TLS version in Client-SSL-Version, normally matching a value such as TLSv1.2 or TLSv1.3.

The same distribution passes completely under system Perl, including the version-header assertion.

Suspected cause

LWP::Protocol::https obtains the metadata from the underlying socket through:

$sock->get_sslversion

PerlOnJava supplies an IO::Socket::SSL compatibility layer backed by Java TLS. The Java bridge has an _get_sslversion implementation that reads the SSLSession protocol, but the CPAN test still receives no usable Client-SSL-Version value. This suggests a mismatch in socket identity, TLS-session access, protocol-string conversion, or metadata propagation between the Java socket and the Perl compatibility layer.

The failure is not an inability to establish HTTPS: the request reaches the server and the test proceeds to inspect the response. It is specifically a missing negotiated-version diagnostic.

Reproduction

Run the LWP::Protocol::https v6.15 test suite under PerlOnJava in an environment where httpbin.org:443 is reachable. t/example.t should fail at the Client-SSL-Version assertion while system Perl passes the complete suite.

A fresh local rerun outside the archived CPAN job could not reach httpbin.org and was skipped by Test::RequiresInternet, so the archived CPAN run is the retained reproduction evidence.

Requested fix

• Trace the negotiated TLS session from Java SSLSocket through IO::Socket::SSL::get_sslversion.
• Ensure the returned protocol string is available as a Perl scalar and has the expected TLSvN.N/SSLvN form.
• Verify that the socket object used by LWP::Protocol::https is the same TLS-upgraded socket exposed by the Java bridge.
• Add a deterministic project-owned regression test for TLS protocol metadata that does not depend on httpbin.org, using a local TLS endpoint or a focused mock socket/session.
• Rerun LWP::Protocol::https t/example.t on both JVM and interpreter backends when network access is available.