[
https://issues.apache.org/jira/browse/THRIFT-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor updated THRIFT-5812:
---------------------------
Description:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads {{82 21 01 04}} (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads {{00 00 00 09}} (which is the
right length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
was:
I am trying to interact with a Rust Thrift server using a Java client. When
using the sync client, the server misreads the length of the message and panics
with a capacity overflow error. However, the async client works fine for some
reason. It happens on both the compact and binary protocols.
When handling a request, the processor calls the protocol’s
{{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
an i32 to check the message length. At this step, for some reason, when the
message has been sent with a sync client, it reads 82 21 01 04 (the Thrift
header, that contains the protocol version, message type and sequence id), when
it has been sent with an async client, it reads 00 00 00 09 (which is the right
length).
I am not sure whether this is an issue on the Rust or Java side (although I
think Rust). Also I am reporting it on version 0.17.0 because it is the latest
available version of thrift on crates.io.
See here for more details and a reproducible example:
[https://github.com/victorbnl/thrift-rs-capacity-overflow].
> Capacity overflow in Rust server
> --------------------------------
>
> Key: THRIFT-5812
> URL: https://issues.apache.org/jira/browse/THRIFT-5812
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
> Affects Versions: 0.17.0
> Reporter: Victor
> Priority: Major
>
> I am trying to interact with a Rust Thrift server using a Java client. When
> using the sync client, the server misreads the length of the message and
> panics with a capacity overflow error. However, the async client works fine
> for some reason. It happens on both the compact and binary protocols.
> When handling a request, the processor calls the protocol’s
> {{read_message_begin}}, which calls the transport’s {{read}}. There, it reads
> an i32 to check the message length. At this step, for some reason, when the
> message has been sent with a sync client, it reads {{82 21 01 04}} (the
> Thrift header, that contains the protocol version, message type and sequence
> id), when it has been sent with an async client, it reads {{00 00 00 09}}
> (which is the right length).
> I am not sure whether this is an issue on the Rust or Java side (although I
> think Rust). Also I am reporting it on version 0.17.0 because it is the
> latest available version of thrift on crates.io.
> See here for more details and a reproducible example:
> [https://github.com/victorbnl/thrift-rs-capacity-overflow].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
