# RustProxy 0.33.8 verification report

This report accompanies the performance and compatibility work on the supplied
0.33.7 source archive and executable. All measurements use disposable local
state. Production data, certificates, configuration and installed services are
not modified. Raw results and exact binary hashes are supplied in the separate
verification archive. The live runners are in `scripts/performance/`.

## Scope and acceptance

The target is reduced work per uncached reverse-proxy request and per local
static-file response while retaining routing, security, cache policy, streaming,
observability and administrative functionality. The LB panel, database schema,
default TLS policy, cache defaults and bounded connection recycling are unchanged.
The performance comparison requires the same compiler, locked dependencies,
release profile, CPU allocation, payloads and client configuration for the
unmodified source and the candidate. The supplied executable is also retained as
an independent compatibility baseline.

Acceptance has separate layers: compilation and Rust tests; source/SQL/upgrade
checks; actual HTTP process tests; actual TLS/H2/H3/WebSocket tests; repeated
before/after/nginx throughput measurements; and a bounded mixed-traffic soak.
A passing source assertion or simulated DOM check is not a live runtime result.
Passing this matrix is not a claim that every possible deployment is covered.

## Baseline findings

The first candidate Rust run completed 658 tests successfully, with 22 failures
and one explicitly ignored formatting microbenchmark. An unmodified-source run
reproduces the old failures; the audit records each stale fixture and each actual
defect separately. The raw initial failed runs remain in the evidence archive.
Tests that expected obsolete behavior are corrected to exercise the currently
documented contract; security, cache invalidation and transport guarantees are
not weakened to obtain a passing result.

The initial live HTTP matrix gave identical results for the supplied executable
and rebuilt 0.33.7: 145 passes, three failures and one skipped optional Brotli
decoder case. All three failures concerned local HTTP/1 file-body completion:
normal responses were recorded as cancelled, and full or empty files failed to
publish a cache entry. The candidate uses a bounded local-file body with accurate
end-of-stream reporting. Arbitrary upstream bodies retain their original trailer
and end-of-stream handling.

The supplied executable passed 111 actual transport assertions covering verified
TLS, H2, H3/QUIC, stream multiplexing, uploads, cache behavior, ranges, validators
and HTTP/1 WebSocket data/control frames. The same runner is used for the final
candidate. The H3 client adapter accounts for HEAD semantics without disabling
GET body-length validation.

## Compatibility checks

The Rust suites exercise cache privacy, Vary and scheme separation, publication
generation barriers, stale access rules, disk tiers, header policies, ACL and
SSRF decision paths, timeout and permit lifetime, actual codecs, filesystem
bounds, symlink policies, range/conditional handling, SQL-backed administration,
TLS configuration, loopback upstream H1/H2 and raw H2 listener behavior. Stream
tests include real TCP/UDP peers. PHP tests use a deterministic FastCGI protocol
peer rather than an installed PHP-FPM application.

The HTTP process runner checks exact response bytes and hashes, streaming before
the final upload chunk, non-replayable POST failures, client cancellation,
configuration reloads, scoped headers and security policy, administration
session/CSRF, cache OFF/ON and privacy behavior, compression and transformations.
The transport runner uses actual local TLS and QUIC connections and trusts the
fixture certificate explicitly.

History-specific tests retain exact log fields, bounded chronological retention,
drop accounting and delivery to live subscribers and configured sinks during
forced history-lock contention. Cloning and destruction of evicted entries occur
outside the history mutex. This preserves the existing best-effort policy;
saturation measurements must still disclose actual history drops.

SQL checks apply all ten migrations twice, exercise named dashboard presets and
account isolation, and verify the 16-preset bound and cascade behavior. The source
upgrade test uses disposable installations to check the stopped-process guard,
held lock rejection, data/configuration preservation, managed source replacement,
backup creation and symlink rejection. Existing JavaScript checks retain their
status as simulated UI checks; no browser acceptance is inferred from them.

## Reproduction

Use the project entry points, which set the private process umask required by
key-store and certificate fixtures:

```bash
./dev.sh check
CARGO_INCREMENTAL=0 ./dev.sh test
python3 scripts/tests/dashboard_presets_sql_test.py
python3 scripts/tests/upgrade_performance_test.py
```

The isolated validation environment uses Rust 1.99.1 with the original locked
dependency versions, nginx 1.26.3 and wrk 4.2.0. See
`scripts/performance/README.md` for live regression, transport, profiling,
benchmark and soak commands. Supply explicit executable paths and new output
directories; preserve failed runs as evidence.

## Measurement boundaries

Throughput measurements use HTTP/1.1 keep-alive, cache OFF, identity encoding,
1040-byte, 64-KiB and 1-MiB objects, separate server/origin/client CPU sets,
interleaved variants and excluded warm-up. Resource samples retain CPU time,
RSS, file descriptors, generator errors and application drop counters. Medians
use all scheduled repetitions. Closed-loop wrk latency is not an open-loop SLA.
Syscall profiles are collected separately from timed throughput runs.

Remaining deployment-specific checks include a 24-hour production-like soak,
remote-network latency and loss, actual PHP-FPM applications, external Tinyauth,
DNS rebinding against a real resolver, and HTTP/2 or HTTP/3 WebSocket tunnels.
The measured same-host comparison does not establish internet-facing capacity.

Final executable-specific outcomes, run counts, percentages and resource costs
are recorded in the separately generated performance/evidence report after the
release build. This embedded document describes the test contract and baseline;
it does not substitute planned work for a completed measurement.