3 posts tagged with "HTTP"

Cloudflare injects cf-ipcity into incoming requests, and for visitors in Vietnam the value is Hồ Chí Minh — with diacritics, which means non-ASCII. Our .NET service forwarded every incoming header verbatim onto its outgoing calls, so that value landed in HttpClient. The surprise is that Headers.Add does not throw, and TryAddWithoutValidation returns true; everything only blows up at SendAsync with HttpRequestException: Request headers must contain only ASCII characters, and not a single byte leaves the process. The bug is neither Cloudflare's nor .NET's — it is in an application that forwards every header unconditionally.

Copying every incoming header onto an outgoing request is an anti-pattern, and it fails in three different directions: correctness (one non-ASCII value makes HttpClient throw), security (you trust and relay data the client set itself), and architecture (headers injected by infrastructure become part of your application's contract). The fix is an allowlist — an explicit list of headers permitted to pass — placed in a shared DelegatingHandler. When you write that handler, mind one trap: it does not live in the request's scope.

Short answer: no, not if you want it to survive every layer. The HTTP specification defines header values in terms of printable ASCII, plus an obsolete branch called obs-text that allows bytes 0x80–0xFF but defines no charset for interpreting them. The consequence is that a Vietnamese string can get through partially: í lives inside Latin-1 and is representable, while ồ is not, because it is U+1ED3 — beyond 0xFF. .NET takes a decisive stance: HttpClient refuses to send any non-ASCII header value. To carry text with diacritics you must encode it, using percent-encoding, RFC 8187 or Base64.