cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4348) Content-Type is broken in multipart serialization
Date Thu, 01 Nov 2012 10:49:20 GMT

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

Sergey Beryozkin commented on CXF-4348:
---------------------------------------

I've just confirmed that AttachmentSerializer on 2.4.x has not been updated to get the optional
parameters dropped. I think I did not update 2.4.x to avoid the possible regressions due to
some sensitivity of the change, given 2.4.9 is now actually the last tag in the 2.4.x line.
So unfortunately the optional parameters will be there indeed on 2.4.x. 

Please migrate to 2.5.x at least where only "multipart/related" will have an optional "start"
parameter included (as confirmed by the tests). 
Also, as I said I'd consider updating the code to get 'start' dropped for non-XOP "multipart/related",
RS endpoint bound payloads - please open a minor issue if you'd like to get it optimized further,
cheers   
                
> 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

Mime
View raw message