Rack has Content-Length mismatch in Rack::Files error responses

## Summary `Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire. Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters. This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value. ## Details `Rack::Files#fail` constructs error responses using logic equivalent to: ```ruby def fail(status, body, headers = {}) body += "\n" [ status, { "content-type" => "text/plain", "content-length" => body.size.to_s, "x-cascade" => "pass" }.merge!(headers), [body] ] end ``` Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value. `Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count. As a result, the server can send more bytes than declared in the response headers. This violates HTTP message framing requirements, which define `Content-Length` as the number of octets in the message body. ## Impact Applications using `Rack::Files` may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters. In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on `Content-Length`, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse. Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components. ## Mitigation * Update to a patched version of Rack that computes `Content-Length` using `String#bytesize`. * Avoid exposing `Rack::Files` directly to untrusted traffic until a fix is available, if operationally feasible. * Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses. * Prefer closing backend connections on error paths if response framing anomalies are a concern.

Quoted source text, attributed separately from HOL analysis.