Skip to main content

Module http

reddb_server::storage::backend

Module http 

Source
Expand description

Generic HTTP RemoteBackend (PLAN.md Phase 2.3).

Speaks plain PUT / GET / DELETE against a configurable base URL. The intent is maximum portability: any custom service that exposes object storage over HTTP — IPFS gateways, in-house storage proxies, ad-hoc backup hosts, anything that takes a body on PUT and serves it back on GET — can serve as RedDB’s backup target without writing a new backend.

Wire contract:

  • PUT {base}/{prefix}{key} — body = file bytes
  • GET {base}/{prefix}{key} — 200 returns body, 404 means “doesn’t exist” (treated as Ok(false) by download)
  • DELETE {base}/{prefix}{key} — 200/204 ok, 404 ignored
  • GET {base}/{prefix}?list=<sub-prefix> — newline-delimited list of keys, one per line

Auth: every request adds the Authorization header from HttpBackendConfig::auth_header. The factory in service_cli reads it from RED_HTTP_AUTH_HEADER_FILE so the actual token never appears in env (Kubernetes Secrets / Vault Agent friendly).

Transport: shells out to curl(1), matching the S3 backend’s choice. No TLS crate baked in, no async runtime requirement, universally available on every Linux/macOS/BSD distro.

Structs§

AtomicHttpBackend
HTTP backend that promises CAS — only constructible when the operator confirmed the upstream server honors RFC 7232 preconditions (If-Match / If-None-Match).
HttpBackend
HttpBackendConfig
Configuration for the generic HTTP backend.