HTTP client and server library for Flyology tasks

HTTP client and server APIs for Flyology.

The client binds requests to one origin and a bounded transport pool. The server keeps each connection and response exchange under one owner. Calls remain synchronous in native and lightweight tasks.

Client guide Server guide
http_client.adb 
Response : Client.Response :=
  Client.Get
    (HTTP, "/status",
     Timeout => 2.0);

Body := Client.Read_All
  (Response, Maximum => 64 * 1_024);
Explicit protocol framingHTTP/1.1 messages and multiplexed HTTP/2 streams retain bounded state.
Bounded retained statePools, bodies, mailboxes, streams, and admission have declared limits.
One monotonic deadlineAdmission, transport setup, I/O, and body consumption share the request budget.

Public interfaces

Client and server share framing policy, not lifecycle state.

Both directions use Flyology I/O and preserve ordinary synchronous call semantics. Their connection and resource ownership remain separate.

01 / CLIENT

Origin-bound client lifecycles

Lease HTTP responses from a bounded pool, or own one WebSocket session through its bounded messages and close handshake.

Client contracts and examples
requestbounded transportresponse
02 / SERVER

Connection-owned exchange lifecycle

Parse and frame responses on the connection owner, with optional routing, middleware, streaming, SSE, WebSockets, and detached native offload.

Server contracts and examples
connectionexchangeresponse

Library boundary

HTTP is built on Flyology.

The library uses task-aware sockets, TLS, files, cancellation, buffers, channels, and structured task scopes from Flyology Runtime. It does not patch the Ada runtime itself.

Inspect the runtime architecture
  1. 01

    Protocol framing

    HTTP/1.1 messages and HTTP/2 frames, compression, flow control, streams, and close behavior remain explicit.

  2. 02

    Application policy

    Routing, body policy, middleware, admission, and native offload compose above the protocol connection.

  3. 03

    Transport waits

    Flyology suspends a lightweight task without blocking its event-loop pthread and preserves the native-task path.

Current scope

Implemented boundaries are part of the interface.

Flyology HTTP is experimental. Validate the exact compiler, host, TLS provider, workload, and operating limits for your application.

Available
HTTP/1.1 client and server, opt-in HTTP/2 client and application-server engines, compatible HTTP/1.0 responses, streaming bodies, routing, middleware, SSE, WebSockets over HTTP/1.1, provider-neutral TLS, and a separate flyology_iri crate for RFC URI/IRI references and WHATWG URLs.
Not available
h2c Upgrade, HTTP/2 server push or WebSockets, proxying, content decoding, challenge-driven client authentication, or a production-qualification claim.
Evidence
Deterministic protocol tests, native/lightweight lane parity, independent HTTP/2 client peer and soak campaigns, HTTP/2 server behavioral tests, a pinned h2spec 2.6.0 run with 146 of 146 tests passing, parser mutation campaigns, and published Autobahn WebSocket reports.