Ivan Bondarenko created CXF-4348: ------------------------------------ Summary: Content-Type is broken in multipart serialization Key: CXF-4348 URL: https://issues.apache.org/jira/browse/CXF-4348 Project: CXF Issue Type: Bug Environment: Any Reporter: Ivan Bondarenko Priority: Blocker
Multiparts are serialized incorrectly. Imagine the response with two attachments: a) "filename1.doc" with attachment-id "Attachment_id1" and Content-Type "application/msword" b) "filename2.xls" with attachment-id "Attachment_id2" and Content-Type "application/vnd.ms-excel" Serialization of this Multipart is ({} are used for text reduction): HTTP/1.1 200 OK Server: ... Date: ... Content-Type: application/octet-stream; type="application/msword"; boundary="uuid:{UUID}"; start="<Attachment_id1>"; start-info="application/msword" Transfer-Encoding: chunked --uuid:{UUID} Content-Type: text/xml; charset=UTF-8; type="application/msword"; Content-Transfer-Encoding: binary Content-ID: <Attachment_id1> Content-Disposition: attachment; filename=filename1.doc {CONTENT1} --uuid:{UUID} Content-Type: application/vnd.ms-excel Content-Transfer-Encoding: binary Content-ID: <Attachment_id2> Content-Disposition: attachment; filename=filename2.xls {CONTENT2} --uuid:{UUID}-- While we are expecting kind of this: HTTP/1.1 200 OK Server: ... Date: ... Content-Type: multipart/related Transfer-Encoding: chunked --uuid:{UUID} Content-Type: application/msword; Content-Transfer-Encoding: binary Content-ID: <Attachment_id1> Content-Disposition: attachment; filename=filename1.doc {CONTENT1} --uuid:{UUID} Content-Type: application/vnd.ms-excel Content-Transfer-Encoding: binary Content-ID: <Attachment_id2> Content-Disposition: attachment; filename=filename2.xls {CONTENT2} --uuid:{UUID}-- So the Content-Type of the whole response and of the first part are incorrect. The starting point of the bug searching is org.apache.cxf.jaxrs.ext.MessageContextImpl.convertToAttachments(Object) method, which has at least these sub-bugs: 1) First attachment is handled other way than all subsequent ones -> All attachments must be handled in the same way. 2) AttachmentOutputInterceptor is created with some default Contetnt-Type, which is "application/octet-stream" -> The type must be "multipart/related" (or other multipart). 3) Content-Type of outMessage is changed to the first attachment's Content-Type and then new type is used at least in org.apache.cxf.attachment.AttachmentSerializer.writeProlog() method -> The same type must be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira