Skip to content

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

Description

@fglock

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:cpan-portCPAN compatibility ports and providersarea:ioFiles handles paths and networkingbugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions