[
https://issues.apache.org/jira/browse/CXF-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Moesel updated CXF-606:
-----------------------------
Attachment: mtom_boundary_bug.patch
Previously mentioned patch (in description).
> MTOM Broken with Axis2 and .NET clients
> ---------------------------------------
>
> Key: CXF-606
> URL: https://issues.apache.org/jira/browse/CXF-606
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0
> Reporter: Chris Moesel
> Attachments: mtom_boundary_bug.patch
>
>
> A recent change to AttachmentDeserializer broke MTOM compatibility with Axis2
> and C# .NET clients. The AttachmentDeserializer no longer looks in
> Content-Type to get the boundary delimiters-- instead it looks in the message
> content input stream. The problem is, it now assumes that boundary
> delimiters will start with "----=_Part_". This is not the case for Apache
> Axis2 or C# clients, so it can't find the boundary delimiters.
> Axis2 uses boundary delimiters like:
> MIMEBoundaryurn_uuid_6BC4984D5D38EB283C1177616488109
> .NET uses boundary delimiters like: --MIMEBoundary633131968239902899
> I am attaching a patch. The patch changes AttachmentDeserializer to first
> look in the Content-Type for the boundary. If it's found, then it uses it.
> If not, only then does it look in the message content input stream. When
> looking in the message content, it does, however, still assume the boundary
> delimiter starts with "----=_Part_". I'm not currently familiar enough with
> boundary delimiter rules to write a better boundary detection scheme.
> Nonetheless, this patch should make handling attachments more efficient
> (since it doesn't always copy out the message content InputStream). And, of
> course, it fixes the Axis2 and C# errors too!
> A unit test is also included so this bug will never happen again. =)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
