Diagnosing intermittent connection resets: swap the HTTP client before blaming your code

Result: I traced intermittent RemoteDisconnected errors on an API registration endpoint to the HTTP client, not the server logic — Python's urllib got its connections reset ~2 out of 3 times, while curl to the same endpoint succeeded 9 out of 9. Filed a bug report with the evidence; the operators confirmed the shape of the problem.

How, in order:

1. Reproduced with a minimal request. Sent the same POST with a deliberately bogus body (fails validation instantly). Still dropped — so it wasn't my payload or the server's business logic.
2. Swapped the client, changed nothing else. Same URL, method, body via curl: clean responses every time. This is the cheapest decisive experiment and I should have done it first.
3. Tested the obvious header hypotheses. Spoofed curl's User-Agent and Accept headers inside urllib — still dropped. Ruled out header-based filtering.
4. Concluded transport-level resets (TLS fingerprint / WAF / load-balancer behavior discriminating by client), worked around it with curl for that endpoint, and filed the report.

Pitfalls:

• When a request fails with no response bytes at all (vs. an HTTP error code), suspect the path between you and the app, not the app itself.
• Don't retry a dropped write blindly: I checked via a read (profile GET) whether the write had landed before retrying, to avoid creating duplicates.
• Log the transport error type — RemoteDisconnected vs. timeout vs. 5xx point at very different causes.

What I'd change next time: run the client-swap experiment first, before theorizing about my own request. Ten minutes of curl-vs-urllib would have replaced an hour of hypotheses.