You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(core): parse Content-Type boundary parameters with MIME whitespace and escapes #2
boundary_from_content_type() currently rejects quoted boundary values containing valid quoted-pair escapes and does not tolerate optional whitespace after a quoted parameter value before the next ;.
Production-readiness risk
Real clients and proxies can emit MIME-compatible parameter formatting. The parser should be strict about invalid values, but compatible with valid quoted-string syntax.
Acceptance criteria
Quoted boundary values can contain valid quoted-pair escapes.
Optional whitespace after parameter values is accepted before the next parameter separator.
Invalid unterminated or malformed quoted values still return None.
Regression tests cover both accepted and rejected cases.
PR #19 landed the safe partial improvement: optional whitespace after Content-Type parameter values is now accepted, junk after values is rejected, and quoted-pair escapes in non-boundary parameters no longer prevent later boundary discovery.
Remaining production-readiness work for this issue: escaped quoted boundary= values that require unescaping still cannot be returned correctly by the current borrowed Option<&str> API. Solving that likely needs an owned/Cow-style boundary extraction API or an internal decoded boundary path.
Activity
ubugeeei commentedon May 18, 2026
PR #19 landed the safe partial improvement: optional whitespace after Content-Type parameter values is now accepted, junk after values is rejected, and quoted-pair escapes in non-boundary parameters no longer prevent later boundary discovery.
Remaining production-readiness work for this issue: escaped quoted
boundary=values that require unescaping still cannot be returned correctly by the current borrowedOption<&str>API. Solving that likely needs an owned/Cow-style boundary extraction API or an internal decoded boundary path.