[
https://issues.apache.org/jira/browse/CXF-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-7684.
------------------------------
Resolution: Fixed
Assignee: Daniel Kulp
Fix Version/s: 3.2.4
3.1.16
> Base64 encoding in AttachmentSerializer does not create correct output for
> large attachments
> --------------------------------------------------------------------------------------------
>
> Key: CXF-7684
> URL: https://issues.apache.org/jira/browse/CXF-7684
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.0.16
> Reporter: Uwe Ryssel
> Assignee: Daniel Kulp
> Priority: Major
> Fix For: 3.1.16, 3.2.4
>
>
> As client, I want to send a SOAP message with base64-encoded attachments. I
> have activated base64 encoding for attachments by adding an out interceptor,
> which sets the message parameter
> org.apache.cxf.message.Message.CONTENT_TRANSFER_ENCODING to "base64", since
> it is supported by the CXF-core's AttachmentSerializer.
> For small attachments, the encoding works. But when I have a large
> attachment, the base64-encoded data is, I think, not valid:
> As implemented in AttachmentSerializer's method encodeBase64(), the encoding
> of the input data is done in blocks of maximum 262144 bytes. Since 262144
> divided by 3 has remainder 1, each of the blocks containing the full 262144
> bytes will generate two '=' padding characters at the end of the block output.
> So for large attachments with > 262144 bytes, the created base64 data stream
> contains padding characters within the stream, and not only at the end. I did
> not find any hint, that this is allowed.
> Especially the server implementation, which I use, interprets the padding
> characters also as end of stream, so that attachments > 262144 do not work in
> that case.
> An fix for this issue would be to use a buffer size, which is divisible by
> three without remainder.
> I still use CXF 3.0.16, since the client have to work with Java 1.6. But
> 3.1.x and 3.2.x use the same method, so the same issue should apply there too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
