Network suites: public HTTP, TLS and DNS test servers (tracking)

[yschimke]

The README says "more suites are planned — notably network tests against external IETF and vendor test servers". This is the plan for those, and the tracking issue for the work.

What this is

A survey of the public servers that other HTTP and TLS clients — curl, rustls, reqwest, Go, the browsers — test against, and a roadmap for pointing the testbed at the ones that tell us something about OkHttp. The full write-up, with what each server offers and why it is worth having, is published at https://yschimke.github.io/okhttp-testbed/topics/test-servers.html.

The two rules the roadmap is written to

1. A test asserting a connection succeeds is fragile against the internet; one asserting it is refused is not. Certificates get renewed, CDNs move, resolvers rate-limit. Prefer negative assertions against public endpoints, and put positive assertions against something we control.
2. Self-host what we can, reach out for what we cannot. go-httpbin and badssl both ship containers, so most of the HTTP-semantics and bad-chain coverage can run in the containers suite with no third party in the loop. The public endpoint then checks the same property against the real internet, and disagreement between the two is the interesting result.

Everything reaching a third party lands in a suite that reports rather than gates, alongside loomTest — a rate limit at Cloudflare is not this repository being red.

Phases

Phase 1 — infrastructure

• Add a network suite that reports rather than gates #6 a network suite module that reports rather than gates
• Endpoint reachability preflight, and endpoint availability on the status page #7 endpoint reachability preflight, and endpoint availability on the status page
• Self-host the test fixtures we depend on #8 self-host the fixtures we depend on

Phase 2 — HTTP

• HTTP semantics against the httpbin family #9 HTTP semantics against the httpbin family
• Hostile and malformed responses #10 hostile and malformed responses
• HTTP/2 against an independent stack #11 HTTP/2 against an independent stack
• HTTP/3 and Alt-Svc: record what OkHttp does today #12 HTTP/3 and Alt-Svc: what OkHttp does today

Phase 3 — TLS

• The badssl matrix: chains that must be rejected #13 the badssl matrix: chains that must be rejected
• TLS version and cipher policy through ConnectionSpec #14 version and cipher policy through ConnectionSpec
• Client certificates against a real server #15 client certificates
• Revocation, pinning and Certificate Transparency #16 revocation, pinning and Certificate Transparency
• Publish the ClientHello OkHttp actually emits #17 publish the ClientHello OkHttp actually emits

Phase 4 — DNS

• The DoH resolver matrix #18 the DoH resolver matrix
• HTTPS and SVCB record consumption #19 HTTPS/SVCB record consumption
• Resolver failure modes: SERVFAIL, DNSSEC bogus, NXDOMAIN #20 resolver failure modes
• Happy Eyeballs against real dual-stack and single-stack names #21 Happy Eyeballs

Phase 5 — ECH beyond the fixture

• ECH against public servers, beyond the local fixture #22 public ECH servers

Not in scope

• Anything needing okhttp3.internal. The public-API-only rule is what makes -PokhttpVersion meaningful, and it is enforced by checkPublicApiOnly.
• Load or performance testing against other people's servers.
• Servers whose terms do not allow automated use. Where a service asks to be used only for clients under your control (How's My SSL), that is what we are doing — one request per scheduled run, no polling.