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

Bắt đầu với t/example.t và lần theo get_sslversion từ LWP::Protocol::https, qua IO::Socket::SSL, đến phần triển khai _get_sslversion của cầu nối Java. Xác minh rằng giao thức phiên của Java SSLSocket đến Perl dưới dạng giá trị TLSvN.N hoặc SSLvN được mong đợi và cùng socket đã được nâng cấp lên TLS được sử dụng. Được xem là hoàn tất khi một kiểm thử hồi quy cục bộ hoặc mock mang tính tất định chạy thành công và t/example.t thành công trên cả hai backend khi có thể truy cập mạng.

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.