This middleware already handle two types of parsing issues
but somehow not this one.

Co-authored-by: Jean Boussier <[email protected]>

This commit restricts the characters accepted in ATTRIBUTE_CHAR,
forbidding control characters and fixing a ReDOS vulnerability.

This also now should fully follow the RFCs.

RFC 2231, Section 7 specifies:

    attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
                         "*", "'", "%", or tspecials>

RFC 2045, Appendix A specifies:

    tspecials :=  "(" / ")" / "<" / ">" / "@" /
                  "," / ";" / ":" / "\" / <">
                  "/" / "[" / "]" / "?" / "="

RFC 822, Section 3.3 specifies:

    CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
                    character and DEL>          ; (    177,     127.)
    SPACE       =  <ASCII SP, space>            ; (     40,      32.)

[CVE-2022-44572]

This commit fixes a ReDoS vulnerability when parsing the
Content-Disposition field in multipart attachments

Thanks to @ooooooo_q for the patch!

[CVE-2022-44571]

This commit fixes a ReDoS problem in `get_byte_ranges`.  Thanks
@ooooooo_q for the patch!

[CVE-2022-44570]

Previously we would limit the number of multipart parts which were
files, but not other parts. In some cases this could cause parsing of
maliciously crafted inputs to take longer than expected.

[CVE-2023-27530]

* 2-2-sec:
  bump version
  Limit all multipart parts, not just files

Split headers on commas, then strip the strings in order to avoid ReDoS
issues.

[CVE-2023-27539]

* 2-2-sec:
  bump version
  Avoid ReDoS problem

This makes Rack 2.2 behavior similar to Rack 2.1 and Rack 3.0 in
regards to underscore in host names.