[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488015#comment-13488015
]
Sergey Beryozkin commented on CXF-4348:
---------------------------------------
Well, http://tools.ietf.org/html/rfc2387 states that 'type' is required, two
other parameters are optional.
Therefore I'm going to close this issue. Please do not hesitate to move this
discussion to CXF Dev list if you do not agree. Thank you
> Content-Type is broken in multipart serialization
> -------------------------------------------------
>
> Key: CXF-4348
> URL: https://issues.apache.org/jira/browse/CXF-4348
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Environment: Any
> Reporter: Ivan Bondarenko
> Assignee: Sergey Beryozkin
> Priority: Blocker
> Labels: bug, multipart, serialization
> Fix For: 2.5.5, 2.6.2, 2.7.0
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
