[
https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488120#comment-13488120
]
Sergey Beryozkin commented on CXF-4348:
---------------------------------------
Ivan, I'm adding one more test. Optional parameters are not there for types
like "multipart/mixed", "multipart/form-data". For "multipart/related" I'm
seeing:
"Content-Type: multipart/related; type="application/xml";
boundary="uuid:cb4e262c-8fa7-4d2a-8744-2801c61680fd";
start="<[email protected]>"".
Note, the only extra parameter is 'start', which is clearly defined in RFC2387
and it is the ContentId of the root part. It is optional all right and I guess
is redundant, but it fits OK for multipart/related. "start-info" is not
included by default and will only be there for XOP payloads.
Thus I do not think we have an issue to be honest. However, please feel free to
open a new Minor issue to get even "start" not reported for 'simple'
multipart/related, I'm open to optimizing it even further though I'd consider
it a minor issue.
Thanks
> 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
