Java Mail fails to parse multipart Content-Type due to slash

[Brian J. Sayatovic]

I've narrowed down a problem I'm experiencing accepting an HTTP post
to a failure of the Java Mail API 1.1 portion of J2EE 1.2.1 to parse
the following Content-Type header:

Content-Type: Multipart/Related;boundary=100fb0c59b90341754298fa8a1cb5fe4;type=text/xml;start="<4d06a28035510812f8c507ecbcad32__>"

The flow is that a javax.mail.internet.ContentType is instantiated
with the value of the header, the type and subtype ("Multipart" and
"Related", respectively) are parsed, and then the paramemter list
needs to be parsed.

The parameter list is parsed by instantiating a
javax.mail.internet.ParameterList with the parameter list value. That
fails with a ParseException with no further information. Through
trial and error, I was able to determine that the forward slash ("/")
in the "type=text/xml" parameter of the parameter list is causing the
problem. By eliminating that slash (or that parameter altogether),
the parsing passes.

The trouble is, as far as I have found, having a slash as part of the
type parameter for a Multipart/Related Content-Type is perfectly legal
and even necessary! Why is it, then, that the Java Mail API can't
handle this?

Regards,
Brian.

 

[Chris Uppal]

The trouble is, as far as I have found, having a slash as part of the
type parameter for a Multipart/Related Content-Type is perfectly legal
and even necessary! Why is it, then, that the Java Mail API can't
handle this?

My reading of RFC 2045 (section 5.1) is that the

type=text/xml

bit is just a "parameter" according to the grammar. As such '/' is not a legal
value in an unquoted value string.

The '/' in Multipart/Related is legal without quotes (indeed quotes would not
be legal there), but that is a different case in the grammar.

In short, I think the content-type line should be (ignore the wrapping):

Content-Type: Multipart/Related; boundary=100fb0c59b90341754298fa8a1cb5fe4;
type="text/xml"; start="<4d06a28035510812f8c507ecbcad32__>"

and that JavaMail is correct to refuse it.

-- chris