Provenance Record

Briefing, 702 words (counted on body_markdown with whitespace tokenization; range 300-800). Clear structure: Overview, What Changed, Why Connections Were Being Abandoned, Manual Workaround, What to Watch, What We Don't Know. Appropriate technical depth.

First-party-only sourcing: both sources are go.dev (the Go project's own blog and release notes), consistent with the allowlist; no independent third-party corroboration, which is appropriate for a story that is the Go team's own announcement and is attributed throughout to the Go Blog / release notes. Read gunzipped snapshots source-0.html.gz (go.dev/blog/http-connection-reuse, HTTP 200, 43841 bytes) and source-1.html.gz (go.dev/doc/go1.27, HTTP 200). Both snapshots are complete (not thin) and were checked against raw text, then re-fetched live via WebFetch; live pages matched snapshots on every checked point. Blog: byline 'Nicholas Husin and Damien Neil', date '14 October 2026' - matches article. Benchmark: 'calling this function 100 times against index.golang.org takes ~710 milliseconds on Go 1.26 on my machine. On Go 1.27, the same program takes ~150 milliseconds.' - article quote is verbatim and attributed to the post/authors; 100 calls, HTTP/1 forced via GODEBUG=http2client=0 (article mentions this in What We Don't Know); the post says 'almost 5 times faster' (710/150 = 4.7), article's 'roughly 5x' is fair; the post notes index.golang.org is worldwide-distributed with relatively low latency and TLS 1.3 (article reports TLS 1.3 / 1 RTT). Drain limits: 'it will asynchronously drain an unread HTTP/1 response body for up to 50 ms or 256 KB' - verbatim; the post does not describe these as configurable or as defaults and the article makes no such claim; the post only adds that behavior 'might evolve in future versions of Go'. Connection: close skip optimization verified. Other quotes verified verbatim: 'abandons the existing connection and creates new connections for its next requests'; 'establishing a new TCP connection can be faster than downloading and discarding the rest of the body'; 'automatically does everything we have implemented in the code above'; 'simply close their HTTP bodies once they no longer need them'; 'Let your code stay clean and simple, and let net/http deal with the complexities on your behalf'; 'might evolve in future versions of Go, as other possible enhancements become apparent'. RTT figures (TCP 1 RTT, TLS 1.2 2 RTT, total 3 RTT), json.Decoder trailing-newline example, and HTTP/2 multiplexing note all match. Release notes (source-1, net/http section; live copy identical per WebFetch): 'HTTP/1 Response.Body now automatically drains any unread content upon being closed, up to a conservative limit, to allow better connection reuse. For most programs, this change should be a no-op, or result in a performance improvement.' verbatim; the rare-degradation passage (MaxIdleConns to 0, different Clients, DisableKeepAlives true, 'usually indicates improper configuration or usage of Transport or Client in the first place') matches. The release notes themselves do not state the 50 ms / 256 KB figures; the article attributes those only to the blog, correctly. suspicious_patterns: null for both sources, nothing to override. No orphan URLs: the only external URLs in the body are the two listed sources; the internal link is /article/2026-08/20-go-127-ships-as-stable-release-finalizing-generic-methods-and-adding-encodingjsonv2 (correct singular form; file src/content/articles/2026-08/20-go-127-ships-as-stable-release-finalizing-generic-methods-and-adding-encodingjsonv2.md exists).

Every number, date, name, quote and attribution traced to a snapshot and confirmed live. The title's 'Cutting ... From About 710 ms to About 150 ms' reflects the authors' own single-machine benchmark; the 'Go Blog:' prefix and the body (Overview attributes to authors; What We Don't Know states single machine, one host, HTTP/2 disabled, no other workloads) keep it from being overgeneralized. Minor, non-blocking nuance: the title does not itself say 'authors' benchmark', and the article does not repeat the post's statement that index.golang.org is a low-latency worldwide-distributed host (it does mention TLS 1.3 and 1 RTT).

Accurate, well-attributed Briefing; all claims, quotes, numbers and dates verified against raw source text, live pages unchanged from snapshots. APPROVE.