…:Directory`.

Escape the root path before interpolating into a regular expression,
preventing RegexpError when the root contains metacharacters and
avoiding path disclosure when regex silently mismatches.

If a wildcard has already been seen as an acceptable encoding,
ignore additional wildcards.

Other improvements while here:

* Only process up to 16 encodings.

* Improve efficiency of candidate sorting.

Add tests for:

* Lower but non-zero wildcard priority

* Multiple wildcards with different priorities

`;` and `,` are allowed as characters inside a quoted value of a
forwarded parameter. So you cannot safely split on those and then
try to remove quotes.

Switch to using a parser based on the one used for parsing
multipart content-disposition.

RFC 1341 specifies there should be a single boundary parameter.
Requests with multiple boundary parameters are unlikely to be
legitimate, and likely are attempts to exploit parsing differences
between rack and web application firewalls.

* Disallow whitespace between boundary and = when parsing multipart boundaries

Rack has historically not accepted these. To avoid security issues
when parsing multiple boundaries, check for boundary cases that may
have whitespace, but explicitly disallow the parsing if there is
whitespace.

Decode path once in applicable_rules before matching, fixing:
- URL-encoded paths bypassing :fonts, Array, and Regexp header rules.
- Path mutation across rules when String rule unescapes inside find_all.
- Array rule values interpolated into regexp without Regexp.escape.

`String#size` returns character count, not byte count. For responses
containing multi-byte UTF-8 characters, this produces an incorrect
`Content-Length` value, violating RFC 9110 Section 8.6.

Allow exceeding this limit by passing max_ranges keyword argument.

If the limit is exceeded, return nil, treating the request as not
requesting ranges. This seems better than returning [], which would
treat the request as requesting no ranges. We use [] when the total
size exceeds the size of the file, as such case is obviously a
problem. However, a request with more than the given number of
ranges is not obviously a problem.

RFC 9110 specifies that allowed characters in a Host header come
from RFC 3986 Section 3.2.2, which provides the following ABNF:

```
      host        = IP-literal / IPv4address / reg-name

      reg-name    = *( unreserved / pct-encoded / sub-delims )

      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

      pct-encoded = "%" HEXDIG HEXDIG

      sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                  / "*" / "+" / "," / ";" / "="
```

This limits the allowed characters to those characters.

This breaks a spec that tests for internationalized domain names.
Such a spec is incorrect as internationalized domain names must be
encoded via punycode in Host headers, so update the specs to
correctly test for the punycode versions.

Mention the substitution is case insensitive in the documentation,
since if the file system is case sensitive, this would be unexpected.

This is similar to the fix of CVE-2026-22860 for Rack::Directory.

Compare the declared `Content-Length` against a configurable maximum (`PARSER_BYTESIZE_LIMIT`) before any parsing begins.

If it exceeds the limit, raise an exception immediately.

This sets a default limit of 8192 escapes, which can be modified
using the RACK_MULTIPART_CONTENT_DISPOSITION_QUOTED_ESCAPES_LIMIT
environment variable.