Error on encodeBase64String when behind SSL connections

[olmeras]

When the app is under an ssl connection it gives me an error like this:

java.lang.IllegalArgumentException: Illegal character(s) in message header value: Basic Y2duZ2tha2k6MTA4ZTdhZmFlZTFkY2EwMTliOWJiMzNjYjNlMDVkODI0NzdiMTA3NA==

I've fixed it by modifying this:

return "Basic " + Base64.encodeBase64String(str.getBytes("UTF-8"));

to this:

return "Basic " + Base64.encodeBase64String(str.getBytes("UTF-8")).replaceAll("(\\r|\\n)", "");

[oohira]

I think your problem is very similar to the following issue.

• new Base64().encode() appends a CRLF, and chunks results into 76 character lines
  • https://issues.apache.org/jira/browse/CODEC-89

I can reproduce the bug if I change commons-codec dependency in pom.xml from 1.9 to 1.4. However, I don't understand why it becomes problem in your environment despite intercom-java uses commons-codec 1.9.

Do you have any idea?

[olmeras]

I don't know either, I can't reproduce the bug on any local environment, it was only happening on the production server. I have recompiled the library with the change I put here and the problem is gone .

[oohira]

In production environment, did you install the app using Maven and confirm commons-codec 1.9 was installed as expected? In an other project, once I have been in trouble because Maven installed older libraries than I specified in pom.xml, though I don't know why.

[olmeras]

After investigating the issue: I'm using Play framework 1, which installs by default the commons-codec-1.4 jar, so I have in production both commons-codec-1.4 and commons-codec-1.9. I'm going to check if I can exclude commons-codec.1.4 from the war that Play generates and if that affects to the application.

[oohira]

@olmeras I close this issue. Let me know if there is any progress or you have the trouble yet.