# RustProxy 0.23.0 specification audit

## Scope

0.23.0 builds on 0.22.3 and adds three control-plane/operations changes: scoped external certificate automation credentials, interactive all-vhost live logs, and a reorganized cache settings UX. Upstream mTLS/client-certificate support remains intentionally deferred.

## External certificate automation

- The administrator can create/rotate/revoke one scoped certificate credential from **Settings → Certificate API**.
- The credential is represented by a non-secret Key ID plus a Bearer Token. Only the token hash is persisted in SQLite schema v5; the cleartext token is returned only by the rotate operation.
- Token authentication is accepted only for `POST /api/certificates/deploy` and `POST /api/certificates/reload`.
- Token authentication does not grant `/api/config`, logs, metrics, certificate inventory, ACME or other administration access.
- Non-loopback token requests require HTTPS. Loopback HTTP remains available for local Certbot hooks.
- Normal administrator session + CSRF authentication continues to work on deploy/reload.
- Direct production CLI operations are `rust-proxy tls deploy ...` and `rust-proxy tls reload`; `dev.sh` is not required.
- Rotation, revoke, deploy and reload operations are audited. Credential status exposes Key ID, creation time and last-used time but never the hash/token.

## Live logs

- `rust-proxy --livelogs` creates a bounded local CLI session and opens an authenticated SSE stream from the running daemon.
- Request handling publishes complete access-log records to a bounded `tokio::sync::broadcast` channel with no await/block in the proxy path.
- The CLI supports structured interactive filters without regex syntax: host, vhost, backend, route, client, method, transport, cache result, exact/status class, path prefix, errors-only and minimum duration.
- `pause`, `resume`, `reset`, `filters`, `clear`, `detail` and `show <id>` provide interactive control and full JSON inspection of recent displayed entries.
- The detailed view includes upstream errors/status, cache reason/effective state, transform effective state, WebSocket bootstrap/phase/error, H3 reset code and byte counters.
- A lagging receiver gets an explicit SSE `gap` event with the number of entries discarded by the bounded channel.
- Session validity is periodically rechecked by the stream endpoint; logout/password-generation changes terminate access.

## Cache settings UX

The existing cache settings IDs and one atomic `cache-form` submission remain unchanged. The UI only groups them into four persistent DOM sub-pages:

1. General
2. Resilience
3. Cold cache
4. Static & diagnostics

No cache setting was removed or split into an independently saved document.

## Production memory hardening

- Inbound HTTP/2 connections now have a five-minute I/O inactivity ceiling. This prevents idle TLS/H2 sessions from accumulating indefinitely toward the process-wide connection semaphore while preserving active streams and normal connection reuse.
- Runtime metrics expose `http2_active_connections`, and Prometheus exports `rust_proxy_http2_active_connections`; the overview HTTP/2 tile shows the live count.
- Hot-cache accounting uses the response body backing allocation capacity before `BytesMut::freeze()`, not only the visible body length, so geometric buffer slack cannot silently bypass `cache.max_bytes`.
- Existing cold-cache demotion/purge allocator trimming remains in place on glibc Linux.

## Open release-host gate

The source includes Rust regression definitions for certificate-token scoping/hash-only persistence and structured live-log filtering/SSE parsing. A compiler-enabled release host must still run the normal `dev.sh check`, `dev.sh test`, release build, live external-token certificate deploy/reload and sustained live-log load acceptance before production deployment.