v0.3

CHANGELOG.md

@@ -1,8 +1,16 @@
 # Changelog
 
-Release history focused on **features, settings, default behavior, compatibility and fixes**. Changes to internal code structure and preliminary performance experiments are intentionally omitted. Historical descriptions reflect their respective releases; consult the current documentation for the settings available in 0.34.1.
+Release history focused on **features, settings, default behavior, compatibility and fixes**. Changes to internal code structure and preliminary performance experiments are intentionally omitted. Historical descriptions reflect their respective releases; consult the current documentation for the settings available in 0.34.2.
 
-## 0.34.1 — development build: explicit configuration, hot reload and API tokens
+## 0.34.2 — configuration storage visibility and public HTTP error responses
+
+- **Settings → Manual config** now reports whether SQLite or an explicit JSON file is the authoritative configuration source, shows its resolved path and distinguishes the SQLite history/audit database from the file-backed active configuration. The authenticated `GET /api/config` response supplies this read-only `storage` metadata without changing the editable JSON schema or write responses; no extra endpoint is needed.
+- Added an optional `systemctl edit rustproxy` example using `--config /etc/rustproxy/config.json` with the required ACLs, owner/mode setup, systemd filesystem allowance, validation and safe reload instructions. The original SQLite configuration mode remains the default.
+- Normalized built-in Web Server errors and proxy-generated non-template errors to ordinary HTTP status bodies (such as `404 Not Found`), without exposing RustProxy diagnostic strings. Preserved status codes, headers such as `Allow`/`Retry-After`, custom error pages, backend-origin responses and authentication behavior.
+- Removed an unused forwarding accessor (`peer_header`) to avoid a Rust `dead_code` warning without changing forwarded header behavior.
+
+
+## 0.34.1 — explicit configuration, hot reload and API tokens
 
 - `--config /absolute/file.json` / `RUST_PROXY_CONFIG`: an existing JSON file becomes the authoritative configuration source. Panel edits and restored revisions are written atomically to that file, with revision history in SQLite. Manual edits are imported by an explicit reload. Fingerprints reject unexpected external changes.
 - `rust-proxy reload` and `rust-proxy config reload` run through the authenticated local admin control plane. The example systemd unit provides `ExecReload` for `systemctl reload rustproxy`; frontends requiring new binds/ALPN still require a service restart.
@@ -11,7 +19,6 @@ Release history focused on **features, settings, default behavior, compatibility
 - Settings supports generate/rotate/revoke for a standalone Prometheus scrape Bearer token. Only its hash is stored. An explicit revocation record overrides legacy environment credentials.
 - Moved RO/RW API token management from **Settings → Administration** to **Settings → Security**; Administration now links directly to the token card.
 
-**Verification:** Development source only. Preflight/static validation is not a Rust build. Native compilation and runtime/security/integration tests are required prior to any production release.
 
 ## 0.34.0 — cache consistency, static delivery and proxy optimization
 
@@ -34,8 +41,6 @@ Release history focused on **features, settings, default behavior, compatibility
 - Preserved protected `X-Request-ID` formatting as **64 lowercase hexadecimal characters**; request IDs now use cryptographically secure 256-bit randomness combined with the process sequence.
 - Preserved response-compression settings, cache exclusions, existing configuration formats and database compatibility. No new mandatory migration or load-balancer control was introduced for these optimizations.
 
-**Validation:** Several later 0.34.0 changes were provided as source changes and require final Rust compilation, regression tests and comparable performance measurements. Earlier candidates passed **151 live HTTP checks** with one optional Zstandard check skipped, but these results do not validate the latest source. No measured RPS advantage over 0.33.8 or nginx is claimed.
-
 ## 0.33.8 — safer file responses and request handling
 
 - Reduced work for requests where caching cannot apply, while retaining independently configured security checks, response transformations and monitoring.