Jens Geyer created THRIFT-6173:
----------------------------------
Summary: Haxe TFullDuplexHttpClient is dead code: guarded by an
undefined conditional and does not compile
Key: THRIFT-6173
URL: https://issues.apache.org/jira/browse/THRIFT-6173
Project: Thrift
Issue Type: Bug
Components: Haxe - Library
Reporter: Jens Geyer
{{lib/haxe/src/org/apache/thrift/transport/TFullDuplexHttpClient.hx}} is dead
code and has been since it was added.
h4. It is compiled out on every target
The file body is wrapped in {{#if swf}}. The Haxe Flash target defines
{{flash}}, not {{swf}}, so the guard never holds. Verified both ways with Haxe
4.2.1:
* a {{#if swf}} block containing a deliberate type error compiles clean under
{{-swf}} (the block is skipped);
* the same block written as {{#if flash}} fails with the expected type error.
So the class body has never been compiled, on any target.
h4. It would not compile if the guard were corrected
Changing the guard to {{#if flash}} and compiling for {{-swf}} gives, in order:
* line 181: {{Type not found : Function}}
* line 240: {{Type not found : Error}}
* {{private var obuffer : Bytes = new Bytes();}} (and {{CRLF}}, and
{{chunkSize}} in {{read()}}) -- {{Not enough arguments, expected length:Int,
b:haxe.io.BytesData}}
* {{chunkSize.writeByte(...)}} -- {{haxe.io.Bytes}} has no {{writeByte}} method
h4. Context
The class came in with THRIFT-2644 (2014) as a port of the ActionScript 3
library, whose own version traces back to THRIFT-1223 / THRIFT-2391. It is
referenced nowhere else in the tree, appears in no build file, and is not
exercised by CI. {{haxelib.json}} publishes the whole {{src}} tree via
{{classPath}}, so it ships in the haxelib package without ever being built. Its
target runtime, Adobe Flash, reached end of life on 2020-12-31.
Removing the file requires no build-file changes.
Related, but not a duplicate: THRIFT-669 asks for chunk-encoded full-duplex
HTTP in the Java library. Nothing in this issue affects that request.
Noticed while sweeping the HTTP transports across bindings for unbounded header
accumulation. The chunk-size loop in this class does accumulate without bound,
which is what drew attention to it -- but since the code is unreachable on
every target, that is not a defect anyone can reach, and this ticket is plain
housekeeping rather than a correctness or security fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
