The MimeType parser in MimeTypeUtils is not fully RFC compliant.
As stated in RFC 2045 Section 5.1:
Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields.
Thus the following two forms
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
are completely equivalent.
In addition to that, "quoted pairs" (i.e. escaped characters) should be unescaped when given to users:
The backslash octet ("") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. Recipients that process the value of a quoted-string MUST handle a quoted-pair as if it were replaced by the octet following the backslash.
This means that given the following MIME type "text/plain; spring="framework\;" should yield:
- type =
text
- subType =
plain
- parameters:
[spring => framework"]
The current parser implementation does does copy the raw parameter value, keeping the " if they are present and not unescaping the quoted pairs.
While we could consider this a bug because our parser is not strictly RFC compliant, such a change can break backwards compatibility and we should introduce this as an enhancement in a minor version.
Note: while working on a prototype parser for this and adding more tests to the existing test suite, I noticed that our current parser has a bug and does not parse quoted values as it should in some cases.
The
MimeTypeparser inMimeTypeUtilsis not fully RFC compliant.As stated in RFC 2045 Section 5.1:
In addition to that, "quoted pairs" (i.e. escaped characters) should be unescaped when given to users:
This means that given the following MIME type
"text/plain; spring="framework\;"should yield:textplain[spring => framework"]The current parser implementation does does copy the raw parameter value, keeping the
"if they are present and not unescaping the quoted pairs.While we could consider this a bug because our parser is not strictly RFC compliant, such a change can break backwards compatibility and we should introduce this as an enhancement in a minor version.
Note: while working on a prototype parser for this and adding more tests to the existing test suite, I noticed that our current parser has a bug and does not parse quoted values as it should in some cases.