BBS:      TELESC.NET.BR
Assunto:  JS http.js: 2nd HTTPS request to same host fails with 'Unable to read
De:       Deucе
Data:     Mon, 25 May 2026 20:43:37 -0700
-----------------------------------------------------------
https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_9065

Not reproducible, and the diagnosis is wrong. Closing as invalid.

## Doesn't reproduce

I ran the supplied repro verbatim against a live install and got three
successful HTTPS calls  `rc=200` on call 1, 2, and 3. No
"Unable to read status" error.

## The hypothesis is incorrect

The report claims `sock.ssl_session = true` caches a per-host TLS session
that becomes stale on the second connection. That's not what
`ssl_session` does. Setting it triggers `cryptCreateSession()` for a
brand-new `CRYPT_SESSION_TLS` on this specific socket  see
`src/sbbs3/js_socket.cpp:2348` (`SOCK_PROP_SSL_SESSION` handler). There
is no per-host TLS session cache in this code path.

Each `HTTPRequest.Get()` call also opens a fresh TCP connection
(`exec/load/http.js:113-127`  closes any previous `this.sock`, then
calls `new Socket()` and `connect()`). The default headers include
`Connection: close` (`http.js:35`), so no keepalive or session
resumption is attempted on the wire either.

## The bug, if real, would break ACME

`exec/load/acmev2.js` is the built-in Let's Encrypt client. It reuses a
single `HTTPRequest` to issue many HTTPS calls to
`acme-v02.api.letsencrypt.org` during cert issuance/renewal. If the
second HTTPS call to a given host always failed, every sysop relying on
the bundled ACME client would have a broken renewal  which isn't what
we see in the field. `exec/init-fidonet.js` similarly pulls multiple
HTTPS URLs in a loop without issue.

## Unverifiable artifacts

The "Impact" section cites `chat_llm.js`, `data/gitissue.jsonl`, and
`data/gitpush.jsonl`. None of these exist in the Synchronet tree or are
produced by any Synchronet component, so the stated impact and
workaround can't be evaluated.

If a real second-HTTPS-call failure does show up against a specific
host, please reopen with: the actual URL, the cryptlib log lines from
that run (`data/error.log` and the per-day terminal-server log under
`data/logs/`), and a single end-to-end transcript of jsexec running the
repro  not a hypothesis.
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

-----------------------------------------------------------
[Voltar]