package https-eio

  1. Overview
  2. No Docs
Authenticated HTTPS client wrapper and shared request helper for Eio

Install

dune-project
 Dependency

Authors

Maintainers

Sources

v0.1.1.tar.gz
md5=b502659cffd9e9bc71d748ce9c512644
sha512=8db8541e2b82fcc58439d9db543b32548f44ee05fd1cf091931da87877f87b96a3d2fd67cd63150b512c501456d0d5d14b8b4d27790535585f28c48d8646868b

Description

Builds the Uri.t -> flow -> Tls_eio.t wrapper that cohttp-eio's client expects for its ~https hook: system CA bundle detection (via ca-certs), a Tls.Config.client, and the one-time Mirage_crypto_rng seed that TLS handshake needs before it can generate any key/nonce material. Extracted from four independent, byte-identical copies of this code (aws-eio's Aws_tls, obs-loki-eio's Obs_loki_tls, obs-prometheus-eio's Obs_prometheus_tls, and Sun's in-tree Kafka_service_tls) after an unseeded-RNG bug had to be hand-ported across all four.

Also exposes request: a timeout-bounded, TLS-wrapped HTTP request built on cohttp-eio, factored out after obs-loki-eio, obs-prometheus-eio, kafka-eio-service, and sun-svc's JWKS fetch each independently rebuilt the same plumbing (validate URL, connect, apply ~https, send, read a bounded response body, classify timeout/network failures) on top of this package's own TLS wrapper. Not a general-purpose HTTP client — no retries, no connection pooling, no redirect handling; callers that need SigV4 byte-fidelity (aws-eio) or connection reuse still build their own transport.

Added to opam-repository:

Dependencies (11)

  1. domain-name >= "0.5.0"
  2. ca-certs >= "1.0.1"
  3. x509 >= "1.0.0"
  4. mirage-crypto-rng >= "2.1.0"
  5. tls-eio >= "2.1.0"
  6. cohttp-eio >= "6.2.0"
  7. http >= "6.0.0"
  8. uri >= "4.4.0"
  9. eio >= "1.3"
  10. ocaml >= "5.4.0"
  11. dune >= "3.0"

Dev Dependencies (3)

  1. odoc with-doc
  2. alcotest with-test
  3. eio_main >= "1.3" & with-test

Used by (1)

  1. aws-eio

Conflicts

None