[jira] [Comment Edited] (THRIFT-3276) Binary data does not decode correctly using the TJSONProtocol when the base64 encoded data is padded.

["Jens Geyer (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14648148#comment-14648148 ] 

Jens Geyer edited comment on THRIFT-3276 at 7/30/15 7:15 PM:
-------------------------------------------------------------

Too bad. Do you by accident :-) already have a patch ready? We accept pull requests and patch files, [see here for details|http://thrift.apache.org/docs/HowToContribute] on how it works.


was (Author: jensg):
Too bad. Do you by accident :-) already have a patch ready? We accepts patch files and PRs, [see here for details|http://thrift.apache.org/docs/HowToContribute] on how it works.

> Binary data does not decode correctly using the TJSONProtocol when the base64 encoded data is padded.
> -----------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-3276
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3276
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Library
>    Affects Versions: 0.9.1
>            Reporter: Steve Niemitz
>
> If the base64 encoded JSON string has padding bytes at the end, the resulting binary data returned in the thrift object ends up with extra padding bytes (0xFF) at the end.
> It seems like this is caused by the TJSONProtocol [using the padded length|https://github.com/apache/thrift/blob/0.9.1/lib/java/src/org/apache/thrift/protocol/TJSONProtocol.java#L760] when it tries to decode the last chunk, which results in the '=' being converted into binary data.  The DECODE_TABLE defaults to -1 (0xFF), which is how it gets into the final output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)