StreamSec Tools 4.x includes a complete HTTPS application layer for Embarcadero Delphi ^TM: an asynchronous TLS server that hosts HTTP/1.1 and HTTP/2 side by side, an HTTPS client, and REST components for both ends of a JSON API — all built directly on the library's own TLS 1.3 and 1.2 implementation.

A first for StreamSec Tools. For two decades StreamSec Tools has been the TLS layer inside other vendors' network stacks — RealThinClient SDK, NexusDB, kbmMW, Indy and Ararat Synapse have all been paired with it to add HTTPS to their own protocol code. Version 4.1.2 is the first release in which the library assumes that role itself. If you have been plugging StreamSec TLS into the RealThinClient (RTC) SDK, StreamSec Tools now stands on its own as a complete replacement for that server stack — the same components serve StreamSec's own web infrastructure, including the support forum and the registered-user download site.

TLS IN THE FOREGROUND

Most Delphi HTTP libraries were designed as cleartext servers first, with TLS patched on afterwards through an "SSL IOHandler" or a similar adapter. StreamSec's server turns that design around and puts TLS where it belongs. TsmAsyncTLSServer is a TLS server first: every connection speaks TLS from the first byte, the application protocol is selected by TLS ALPN during the handshake, and no connection reaches application code without an established TLS session. Certificate selection, OCSP stapling, mutual TLS, session resumption, 0-RTT policy and post-quantum key exchange are configured on the server itself — not threaded through an add-on that the HTTP layer was never designed for.

HTTP/1.1 AND HTTP/2 ON ONE SERVER, CLEANLY

HTTP/1.1 and HTTP/2 are different wire protocols, but they are one application — and the server treats them that way. Each protocol is a plugin component (TsmHTTPSv1dot1 and TsmHTTPSv2), ALPN decides per connection which one answers, and both dispatch into one shared request router. You register a handler once — a static file, a per-path event or a handler interface — and it responds identically whether the client negotiated h2 or http/1.1. Cookies, sessions, client-certificate facts and the negotiated TLS parameters are presented through the same request interface on both wires. HPACK header compression, stream multiplexing and flow control stay inside the HTTP/2 plugin; your code never sees a frame.

BUILT FOR CONCURRENCY, HARDENED BY DEFAULT

• Asynchronous reactor core: I/O completion ports on Windows, epoll on Linux, kqueue on macOS
• Sharded TLS engines, so handshakes run in parallel across CPU cores
• Every resource bound is published and tunable: header and body budgets per request, per connection and per server, send-queue bounds, handshake and idle deadlines
• Strict HTTP/1.1 request framing (request-smuggling defences) and protection against the published HTTP/2 abuse patterns (flood, rapid-reset and header-bomb families)

THE COMPONENTS

• TsmAsyncTLSServer — the asynchronous TLS server that hosts the protocol plugins
• TsmHTTPSv1dot1 and TsmHTTPSv2 — HTTP/1.1 and HTTP/2 (RFC 9113) server plugins over one shared router
• TsmHTTPSClient — HTTPS client with the same trust model as the rest of the library
• TsmRESTClient and TsmRESTServer — JSON REST on both ends: authentication seams, idempotency keys, RFC 9457 problem+json errors
• TsmAcmeClient — automated certificate issuance and renewal (ACME, as used with Let's Encrypt)

PROVEN AGAINST INDEPENDENT PEERS

Like the TLS stack itself, the HTTP layer is tested against implementations we did not write: curl over HTTP/1.1, OpenSSL's ALPN client and the Node.js HTTP/2 client, plus everyday browsers against our production server. Interoperability is measured, not assumed.