Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#1,435 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
java, perl

调研方向

从 t/example.t 开始,跟踪 get_sslversion 从 LWP::Protocol::https 经过 IO::Socket::SSL 到 Java bridge 的 _get_sslversion 实现。验证 Java SSLSocket 的会话协议是否以预期的 TLSvN.N 或 SSLvN 值传递到 Perl,并且使用的是同一个已升级为 TLS 的 socket。在网络访问可用时,确定性的本地或 mock 回归测试通过,且两个 backend 上的 t/example.t 均成功,即表示完成。

由索引模型根据 Issue 内容生成。

描述

area:cpan-port area:io bug

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.
主要语言
Perl
星标
64
派生
6
平均合并
5 小时 38 分钟
30 天内合并 PR
170

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

fglock/PerlOnJava 的其他 Issue

查看 fglock/PerlOnJava 的全部 Issue

相似的 Issue

更多 Perl Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。