Every explicit proxy currently produces a warning that latency and throughput measure only the client→proxy leg. That conclusion does not follow from detecting a proxy.
With an ordinary CONNECT tunnel, TCP connects to the proxy, but TLS and HTTP continue through the tunnel to the origin. Throughput also depends on the full tunneled path. The stage timings therefore have different semantics; a single client→proxy description misleads consumers interpreting the result.
This is present in implementation, CLI output, result comments, README, and the PROXY spec. The existing proxy integration test already uses a forwarding CONNECT tunnel, so this is a correction to the product contract as well as wording.
Evidence: warning construction, CLI output, RFC 9110 CONNECT semantics.
Acceptance criteria:
- Report explicit proxy routing separately from evidence of TLS interception/private-CA use.
- Explain the measured path of TCP, TLS, HTTP, and throughput without inferring interception or the bottleneck location from proxy presence alone.
- Treat certificate-based interception detection as evidence with its documented limitations, not proof that all traffic terminates at a proxy.
- Add a controlled CONNECT test with delay between proxy and origin to verify that the reported HTTP/TLS measurements include the onward path.
- Correct the PROXY spec, README, result comments, and CLI together; review JSON compatibility requirements if field meaning changes.
- Preserve credential stripping and existing proxy/test_endpoint behavior.
Related: PROXY-1 through PROXY-7, INV-3, INV-7. Confirm spec edits before commit.
Every explicit proxy currently produces a warning that latency and throughput measure only the client→proxy leg. That conclusion does not follow from detecting a proxy.
With an ordinary CONNECT tunnel, TCP connects to the proxy, but TLS and HTTP continue through the tunnel to the origin. Throughput also depends on the full tunneled path. The stage timings therefore have different semantics; a single client→proxy description misleads consumers interpreting the result.
This is present in implementation, CLI output, result comments, README, and the PROXY spec. The existing proxy integration test already uses a forwarding CONNECT tunnel, so this is a correction to the product contract as well as wording.
Evidence: warning construction, CLI output, RFC 9110 CONNECT semantics.
Acceptance criteria:
Related: PROXY-1 through PROXY-7, INV-3, INV-7. Confirm spec edits before commit.