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

ASF GitHub Bot commented on THRIFT-3276:
----------------------------------------

GitHub user nsuke opened a pull request:

    https://github.com/apache/thrift/pull/645

    THRIFT-3276 Binary data does not decode correctly using the TJSONProt…

    …ocol when the base64 encoded data is padded.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/nsuke/thrift THRIFT-3276

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/thrift/pull/645.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #645
    
----
commit aa8ec9ef94372ca8035b2c90d7efa07ddf326880
Author: Nobuaki Sukegawa <[email protected]>
Date:   2015-10-10T01:44:07Z

    THRIFT-3276 Binary data does not decode correctly using the TJSONProtocol 
when the base64 encoded data is padded.

----


> 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: C++ - Library, 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)

Reply via email to