[CXF-4347] Content-Type is broken in multipart serialization

• Type: Bug
• Status: Closed
• Priority: Blocker
• Resolution: Duplicate
• Labels: bug multipart serialization

Environment

Any

• Estimated Complexity: Unknown
• Assignee: Sergey Beryozkin
• Reporter: Ivan Bondarenko
• Created: 29/May/12 11:22
• Updated: 30/May/12 08:41
• Resolved: 30/May/12 08:41

Description

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.

Issue Links

• duplicates: CXF-4348 Content-Type is broken in multipart serialization