jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • groovy
  • GROOVY-2878

byte[].encodeBase64() incorrectly introduces line breaks

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.5
  • Fix Version/s: 1.5.7, 1.6-beta-2
  • Component/s: None
  • Labels:
    None

Description

Groovy's encodeBase64 inserts 0x0A chars (LF) into long strings to break lines. This is contrary to my reading of RFC4648:

{codec}
3.1. Line Feeds in Encoded Data

MIME [4] is often used as a reference for base 64 encoding. However,
MIME does not define "base 64" per se, but rather a "base 64 Content-
Transfer-Encoding" for use within MIME. As such, MIME enforces a
limit on line length of base 64-encoded data to 76 characters. MIME
inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
that it is "virtually identical"; however, PEM uses a line length of
64 characters. The MIME and PEM limits are both due to limits within
SMTP.

Implementations MUST NOT add line feeds to base-encoded data unless
the specification referring to this document explicitly directs base
encoders to add line feeds after a specific number of characters.{codec}

This has resulted in incorrect behaviour in Grails also. However the author notes that some groovy applications may rely on this functionality currently, so this could be a breaking change for some.

It would be better to be correct IMO. There is no clue in groovy docs that this introduces line breaks in this MIME/SMTP specific way.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
blackdrag blackdrag added a comment - 02/Jun/08 7:55 AM

looks like the current implementation adds a line-break each 18 bytes

Show
blackdrag blackdrag added a comment - 02/Jun/08 7:55 AM looks like the current implementation adds a line-break each 18 bytes
Hide
Permalink
Alexander Veit added a comment - 02/Jul/08 5:23 PM

+1 for changig the encodeBase64() method to be compliant to RFC 4648. The presence of non-Base64 characters in the encoded data also makes the decodeBase64() method less efficient than it could be, since it prevents the decoder to preallocate a byte array of exactly the size of the decoded output.

However, there are frequently use cases that require multiline Base64 encoding. An encoder that could support these use cases would probably need at least four aditional parameters:

  • a line separator string,
  • an indentation string (not to be applied to the first encoded line),
  • a maximum line length (inluding indentation and line separator strings), and
  • an offset for the first encoded line.
Show
Alexander Veit added a comment - 02/Jul/08 5:23 PM +1 for changig the encodeBase64() method to be compliant to RFC 4648. The presence of non-Base64 characters in the encoded data also makes the decodeBase64() method less efficient than it could be, since it prevents the decoder to preallocate a byte array of exactly the size of the decoded output. However, there are frequently use cases that require multiline Base64 encoding. An encoder that could support these use cases would probably need at least four aditional parameters:
  • a line separator string,
  • an indentation string (not to be applied to the first encoded line),
  • a maximum line length (inluding indentation and line separator strings), and
  • an offset for the first encoded line.
Hide
Permalink
Paul King added a comment - 03/Jul/08 5:27 AM

Do the versions of encodeBase64 which accept the non-chunked boolean help the Grails issue? (In trunk only).

Show
Paul King added a comment - 03/Jul/08 5:27 AM Do the versions of encodeBase64 which accept the non-chunked boolean help the Grails issue? (In trunk only).
Hide
Permalink
Paul King added a comment - 29/Aug/08 7:03 AM

Can I assume the changes in trunk for GROOVY-2906 mean that we can close this issue?

Show
Paul King added a comment - 29/Aug/08 7:03 AM Can I assume the changes in trunk for GROOVY-2906 mean that we can close this issue?
Hide
Permalink
Paul King added a comment - 18/Jun/09 8:19 AM

No further feedback, asuming fixed.

Show
Paul King added a comment - 18/Jun/09 8:19 AM No further feedback, asuming fixed.

People

  • Assignee:
    Paul King
    Reporter:
    Marc Palmer
Vote (0)
Watch (1)

Dates

  • Created:
    02/Jun/08 6:45 AM
    Updated:
    15/Oct/09 5:31 PM
    Resolved:
    18/Jun/09 8:19 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.