Thanks for the detailed feedback, appreciate you taking the time to dig into this.

On the redirect chain point: this is already handled. The fetcher re-runs the full SSRF validation (DNS resolution + private/loopback/link-local/reserved/cloud-metadata IP check) on every redirect hop, not just the initial request, so a chain that resolves to 169.254.169.254 or any other internal range on hop two gets blocked exactly the same as if it were the first request.

There's a dedicated test for this exact scenario, test_redirect_to_private_ip_is_blocked, which mocks a public host issuing a 302 to 169.254.169.254/latest/meta-data and asserts the request is rejected with SSRF validation confirmed on both hops. It's currently passing.

I also wrote a full technical breakdown of this exact failure mode (DNS TTL flip between the safety check and the actual connection, redirect chains sneaking past validation, the 169.254.0.0/16 block) in a separate article titled "How to Safely Fetch Metadata from User-Submitted URLs (Without Getting Hit by SSRF or DNS Rebinding)" on Dev.to, if you're curious about the implementation details. My account here is too new to post links yet, but it's easy to find by title.

On the buffer point: the 256KB ceiling isn't the default, it's a ceiling. The soft limit is 64KB, and it only expands to 256KB when SPA framework signatures (Next.js, React, Vue, etc.) are detected in the first bytes, so small static pages don't pay for it.

Good points on TLS handshake and TTFB dominating p99. That's true and not something the parsing layer can do much about.