Promoted out of :mod:flare.http.server (which was the originating
site for the helper but is the wrong layer -- it is the reactor-
coupled dispatcher, not the sans-I/O parser surface).
Why it lives here
The pattern -- "construct a Mojo String from a byte span without
re-running the stdlib's full UTF-8 validator" -- belongs in the
proto layer because every consumer is parser-shaped: HTTP/1.1 wire
artefacts (method, URL, version, header name, header value),
HTTP/2 control frame fields, WebSocket control-frame text payloads,
gRPC trailers-only field names, and so on. The bytes have
already passed the protocol's own RFC 7230 / RFC 9110 / RFC 7540 /
RFC 6455 token / VCHAR / TCHAR check upstream, so the additional
stdlib UTF-8 validation is dead work.
The helper showed up as the single hottest user-space symbol in
perf record against the H1 plaintext bench (~5% of CPU); this
module is the namespace it lives in so every parser layer can
reach for it consistently.
Caller contract
Inputs MUST already be valid ASCII (every byte < 0x80). The
helper does not check; calling it on non-ASCII bytes produces an
incorrectly-encoded String (each byte becomes a one-byte UTF-8
sequence, which is correct iff every byte is < 0x80). HTTP/1.1
wire artefacts satisfy this through the parser's RFC 7230 token /
VCHAR check; HTTP/2 token-shaped fields satisfy it through HPACK's
RFC 7541 §4 ASCII-only contract; WebSocket text frames do not
satisfy it (those carry UTF-8 by spec) -- the codec there must
keep using String(unsafe_from_utf8=...).
Public API
- :func:
ascii_unchecked_string(span: Span[UInt8, _]) -> String --
construct a String of the same byte length from span via
String(unsafe_uninit_length=n) + memcpy. Empty input
returns String("").
- :func:
ascii_lower(s: String) -> String -- return an ASCII-
lowercase copy of s using a single unsafe_uninit_length
allocation. The pure-ASCII fast path skips the per-byte branch.