BBS:      TELESC.NET.BR
Assunto:  JS http.js: 2nd HTTPS request to same host fails with 'Unable to read
De:       Rob Swindell
Data:     Mon, 25 May 2026 21:45:09 -0700
-----------------------------------------------------------
https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_9068

Two corrections to my prior follow-up:

**Log-file references were wrong.** The closing line suggested capturing `data/error.log` + the per-day Terminal Server log if it resurfaces on Windows. Neither captures a `jsexec` failure  `data/error.log` is the server-side `errormsg()`/`LOG_ERR` sink, and `data/logs/.log` records Terminal Server *sessions*. `jsexec` is standalone and writes only to its own stdout/stderr (or `-L ` / `-e `). The actually useful diagnostic here would be the cryptlib status code/string from the failing socket op, surfaced through `js_socket.cpp`  which currently propagates only as a bare `"Unable to read status"` JS exception with no underlying error context. A small `lprintf` or exception-message enrichment that includes the cryptlib reason would make this kind of bug far easier to triage next time.

**"If it resurfaces on Windows" understates the state.** It hasn't gone away. It reproduces 100% on Windows against current master in both Release (`master/edf752429`) and Debug (`master/0db1c34fc`) builds with the verbatim repro from this issue. The Linux non-reproduction localizes the bug; it doesn't fix it. Leaving the issue closed since the original report misdiagnosed the cause, but the underlying Windows failure is reliably present, not a "watch for it" item.

 *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

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