> In the C# version the start is different? > \x00\x00\x00\x82 > vs > \x80\x01\x00\x01
Right, and now that I look at it, I guess I know what the issue might be > \x00\x00\x00\x82 This is not a message header. It is the 4-byte length indicator of the TFramedProtocol. The remainder of the message is 0x82 = 130 bytes. Could it be that the setup of the Thrift protocol/transport stack differs between the two clients? What happens if you add TFramedProtocol to the Python version? I'm just not quite sure about this part that follows immediately: > \x0f\xff\x00\x01\x00\x00\x00\x01\x00\x01\x00\x00\x00\x00 From looking at the naked bytes, I have no idea what that could be. But that may again become clearer, if you check the Thrift protocol/transport stack setup used. After that, the usual header etc follows: > \x80\x01\x00\x01 message header \x00\x00\x00\x04auth string length and message name etc. -----Ursprüngliche Nachricht----- From: C Bergström Sent: Tuesday, March 12, 2019 2:54 AM To: user@thrift.apache.org Subject: Re: Python client vs C# client json/binary different.. a lot of extra comma!! (confused) I'll double check the bytes question below. I will probably need to spend 1 day writing a parser for this though. In the C# version the start is different? \x00\x00\x00\x82 vs \x80\x01\x00\x01 Is this just a different version of Thrift header? The binary looked so different, but it should have been a similar length. I'll try to parse it and see what I can understand. On Tue, Mar 12, 2019 at 9:35 AM Jens Geyer <jensge...@hotmail.com> wrote: > Ok, I decoded the first part for you: > Thanks! > > > Python New > > \x80\x01\x00\x01 > Thrift message header > > > \x00\x00\x00\x04 > string length = 4 > > > auth > the string data = message name > > > \x00\x00\x00\x00 > msg sequence nr > > > \x08 > field type = 8 = i32 > > > \x00\x01 > field ID = 1 > > > \x00\x00\x9cB > i32 value = 0x9c00+66 = 40002 > > > \n > field type = 10 = i64 > > > \x00\x02 > field ID = 2 > > > \x00\x00\x00\x00\x03\x89\x05\x8a > i64 value = 0x0389058a = 59311498 > > > \x0b > field type = 11 = string > > > \x00\x03 > field ID = 3 > > > \x00\x00\x00 > string len ... should be 4 bytes ... is there one byte missing? or did you > only lose it somewhere between debugger and email? > > > ED237CF629A6CD7AF601659A39CECFDC > string data = 16 bytes > > > \x0b > field type = 11 = string > > > \x00\x04 > field ID = 4 > > > \x00\x00\x00\x1a > string len = 0x1a = 26 > > > c#/unity,1.0 > > beta,20141223 > string data, as shown (incuding the line break) > > > \r > > field type = 13 = map<> > > > \x00\x05 > > field id = 5 > > > \x0b > map key field type = 11 = string > > > \x0b > map value field type = 11 = string > > > \x00\x00\x00\x00 > number of entries in the map = 0 > > > \x00 > field type = T_STOP > > So the only thing that looks strange is the length indicator right before > "ED237CF629A6CD7AF601659A39CECFDC". But I can't really imagine that python > only writes 3 of 4 bytes, that should have been found and fixed long ago > if > such a bug ever existed. > > Could you double-check that please? > > > > > > > > > > > >
