Ivan Bondarenko created CXF-4347:
------------------------------------
Summary: Content-Type is broken in multipart serialization
Key: CXF-4347
URL: https://issues.apache.org/jira/browse/CXF-4347
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
