[
https://issues.apache.org/jira/browse/THRIFT-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789451#comment-16789451
]
Jack Flecher edited comment on THRIFT-4815 at 3/11/19 11:47 AM:
----------------------------------------------------------------
I can confirm that indeed the p.writeFieldN calls are all in the right order
however the actual data that gets flushed by the TTransport suggests otherwise.
The TTransport I use is the THttpClient, so in this specific case the data I
am referring to is accessable in the Flush function of the file http_client.go
in the actual go Thrift library.
{code:java}
func (p *THttpClient) Flush(ctx context.Context) error {
// Close any previous response body to avoid leaking connections.
p.closeResponse()
req, err := http.NewRequest("POST", p.url.String(), p.requestBuffer)
// fmt.Println(p.requestBuffer.String())
if err != nil {
return NewTTransportExceptionFromError(err)
}
req.Header = p.header
if ctx != nil {
req = req.WithContext(ctx)
}
response, err := p.client.Do(req)
if err != nil {
return NewTTransportExceptionFromError(err)
}
if response.StatusCode != http.StatusOK {
// Close the response to avoid leaking file descriptors.
closeResponse does
// more than just call Close(), so temporarily assign it and
reuse the logic.
p.response = response
p.closeResponse()
// TODO(pomack) log bad response
return NewTTransportException(UNKNOWN_TRANSPORT_EXCEPTION, "HTTP
Response code: "+strconv.Itoa(response.StatusCode))
}
p.response = response
return nil
}
{code}
I will update the IDL, my bad.
I will also get that repo up later today.
was (Author: tmjbunny):
I can confirm that indeed the p.writeFieldN calls are all in the right order
however the actual data that gets flushed by the TTransport suggests otherwise.
The TTransport I use is the THttpClient, so in this specific case the data I am
referring to is accessable in the Flush function of the file http_client.go in
the actual go Thrift library (fmt.Println(p.requestBuffer.Bytes())).
I will update the IDL, my bad.
I will also get that repo up later today.
> Golang thrift and Python don't write the same messages
> ------------------------------------------------------
>
> Key: THRIFT-4815
> URL: https://issues.apache.org/jira/browse/THRIFT-4815
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler, Go - Library, Python - Compiler, Python -
> Library
> Affects Versions: 0.11.0, 0.12.0
> Environment: Python:
> Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64
> bit (AMD64)] on win32
> Thrift version 0.11.0 tested.
> Golang:
> Thrift versions 0.12.0 and 0.11.0 tested
> go version go1.11.4 windows/amd64
> go env:
> set GOARCH=amd64
> set GOBIN=
> set GOCACHE=C:\Users\BUNNY\AppData\Local\go-build
> set GOEXE=.exe
> set GOFLAGS=
> set GOHOSTARCH=amd64
> set GOHOSTOS=windows
> set GOOS=windows
> set GOPATH=C:\Users\BUNNY\go
> set GOPROXY=
> set GORACE=
> set GOROOT=C:\Go
> set GOTMPDIR=
> set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
> set GCCGO=gccgo
> set CC=gcc
> set CXX=g++
> set CGO_ENABLED=1
> set GOMOD=
> set CGO_CFLAGS=-g -O2
> set CGO_CPPFLAGS=
> set CGO_CXXFLAGS=-g -O2
> set CGO_FFLAGS=-g -O2
> set CGO_LDFLAGS=-g -O2
> set PKG_CONFIG=pkg-config
> set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments
> -fmessage-length=0
> -fdebug-prefix-map=C:\Users\BUNNY\AppData\Local\Temp\go-build552047466=/tmp/go-build
> -gno-record-gcc-switches
> Reporter: Jack Flecher
> Priority: Blocker
> Labels: newbie
> Attachments: bunny.thrift
>
>
> I'm trying to port a tool that relies on Thrift from Python to Golang, it is
> a client not a server.
> The thrift protocol behaves inconsistent when comparing Python and Golang and
> it results in breaking applications.
> What it boils down to is I have a struct called Message with a certain amount
> of fields and I have a sendMessage method that takes that message and sends
> it to a server which then processes that.
> In Python I can simply make a Message object, set some user's userId as
> receiver and the text after which I can send the message using sendMessage()
> In Golang I can do the exact same but I run into error responses from the
> server saying another field that isn't required cannot be found.
> In Python this is the generated POST body sent to the server:
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x04test\x00\x00'
> b'\x82!\x00\x0bsendMessage\x15\x00\x1c(!u218891b1a7af4d21ffe4918acbeb9a73\x88\x05test2\x00\x00'
> In Golang the generated POST body sent to the server:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> b'\x82!\x02\x0bsendMessage\x15\x00\x1c(\x05test2\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> As demonstrated above therre are two differences in the generated POST bodies
> but the one causing the error is the fact that the fields are in a different
> order than they are supposed to.
> In Golang trying to reverse the order of the fields causes this POST body to
> be generated:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c\xa8!u218891b1a7af4d21ffe4918acbeb9a73\x08\x04\x04test\x00\x00'
> When commenting out all the fields I actually don't want to be written and
> then only reversing the functions that are actually writing data, the ones
> for the receiver and text fields the POST body looks like this:
> b'\x82!\x01\x0bsendMessage\x15\x00\x1c(\x04test\x88!u218891b1a7af4d21ffe4918acbeb9a73\x00\x00'
> To summarize, the Thrift protocol on Golang is broken in certain cases
> because fields are not written in the right order causing other
> implementatings of Thrift to stop serving Golang Thrift clients.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
