thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Voellmy <andreas.voel...@gmail.com>
Subject Re: String encoding in Haskell Thrift
Date Sat, 16 May 2015 19:37:20 GMT
Actually, I think I may have found the answer. I think I should have the
server and client use binary in the thrift definition rather than string.
Then Haskell will also not apply encoding, and so should be consistent with
the server.

On Sat, May 16, 2015 at 2:50 PM, Andreas Voellmy <andreas.voellmy@gmail.com>
wrote:

> Hi all,
>
> I've got a service written in one language (C++ or Python) that has a
> service API with a string parameter that really is a byte array where the
> bytes can have values > 127. The server does not seem to use UTF8 for
> decoding.
>
> Then I've got a client using the Haskell thrift library + generated code
> sending the byte array as string to the server.
>
> The problem is that the Haskell code generated by Thrift first encodes all
> strings using UTF8, which are then interpreted badly on the server side
> whenever the byte values are over 127.
>
> I noticed a long discussion [1] relating to exactly the same issue
> noticing that Java does the UTF8 encoding where Python doesn't. I think
> this is the same issue, this time with Haskell.
>
> For the time being, I've changed the Haskell code-generator so that the
> Haskell code does not apply UTF encoding. What is the right way to resolve
> this issue of sending a byte array from one thrift client to another?
>
> [1] https://issues.apache.org/jira/browse/THRIFT-395
>
> -Andi
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message