Yuxuan Wang created THRIFT-5183:
-----------------------------------
Summary: [Go] Read beyond current frame in THeaderTransport might
block the protocol code
Key: THRIFT-5183
URL: https://issues.apache.org/jira/browse/THRIFT-5183
Project: Thrift
Issue Type: Improvement
Components: Go - Library
Affects Versions: 0.13.0
Reporter: Yuxuan Wang
This is a bug introduced in my initial implementation of go THeader in
https://github.com/apache/thrift/commit/4d46c1124450eeb77d2a6adc7ea5fab304bfeb4a.
In THeaderTransport.Read implementation, after finished reading the current
frame, we try to read the next frame to fill the rest of the reading buffer:
https://github.com/apache/thrift/blob/df2f5d2cf321f070a356872eea13dd3f68891043/lib/go/thrift/header_transport.go#L502-L506
This is actually a wrong behavior. At the end of frame, the other end is highly
likely awaiting for the response, and very unlikely to send anything for the
next frame. So this behavior could potentially cause a blocking read an
eventually lead to timeout.
Currently the two supported wrapped protocol under THeaderProtocol are
TBinaryProtocol and TCompactProtocol, I checked the code and neither of them
will actually use a more than enough buffer for the Read call to the transport,
so this bug shouldn't be causing any real issues yet. But it's still a bug
worth fixing.
I already have a fix ready, will send out the PR after this ticket is created.
Ironically, this bug is actually very similar to the bug in TFrameTransport
that I fixed in that commit :(
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
