Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-7684

Base64 encoding in AttachmentSerializer does not create correct output for large attachments

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 3.0.16
    • 3.1.16, 3.2.4
    • Core
    • None
    • Unknown

    Description

      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.

      Attachments

        Activity

          People

            dkulp Daniel Kulp
            uwe_r Uwe Ryssel
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: