[jira] [Comment Edited] (CXF-4348) Content-Type is broken in multipart serialization

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285795#comment-13285795 ] 

Sergey Beryozkin edited comment on CXF-4348 at 5/31/12 9:55 AM:
----------------------------------------------------------------

Ivan,

> 2) AttachmentOutputInterceptor is created with some default Content-Type, which is "application/octet-stream" -> The type must be "multipart/related" (or other multipart).

note that the method in your code @Produces("multipart/*"). I can reproduce that the response message's Content-Type is set to "application/octet-stream", but only if no "Accept: multipart-related" exists. If I update the client to set "Accept: multipart-related", then the message Content-Type is set correctly to multipart-related, with other parameters like start-info, etc, included.

Can you confirm that you have a specific multipart media type listed in Accept ?

I can confirm that the Content-Type of the root part only is broken for outbound attachments. Will be fixing it



                
      was (Author: sergey_beryozkin):
    Ivan,

> 2) AttachmentOutputInterceptor is created with some default Content-Type, which is "application/octet-stream" -> The type must be "multipart/related" (or other multipart).

note that the method in your code @Produces("multipart/*"). I can reproduce that the response message's Content-Type is set to "application/octet-stream", but only if no "Accept: multipart-related" exists. If I update the client to set "Accept: multipart-related", then the message Content-Type is set correctly to multipart-related, with other parameters like start-info, etc, included.

Can you confirm that you have a specific multipart media type listed in Accept ?

I can confirm that when we have more than one part returned, the Content-Type of the root part is broken. Will be fixing it



                  
> 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
>            Priority: Blocker
>              Labels: bug, multipart, serialization
>
> 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