haxe.Http's handling of responses that have no explicit length is broken

TL;DR it's possible that under certain conditions reading from a socket returns -1 with errno set to ECONNRESET (Connection reset by peer) which depending on the application-level may or may not be an error but there's no way to distinguish that from other errors, neither using the Haxe networking API, let alone using haxe.Http.

It can (and usually should) be an application-level error, but not in all cases. HTTP without explicit length (meaning neither chunked transfer-encoding is used nor an explicit Content-Length is provided) allows this, for instance - the client simply is supposed to read until the connection is closed. Under certain circumstances - the client already shut down the connection and the server closed the connection, too, it's possible that instead of returning 0 (which usually signals the connection was closed) read/recv/etc. return -1 with ECONNRESET, which is not actually an application-level error in this case - but haxe.Http passes on whatever exception it received from the underlying socket implementation, and the data, which may well be valid and complete, is lost, (the onError callback is triggered, the onData callback is not).

At this point, and in the state the haxe networking API is in, I think we have no choice but to treat all haxe.io.Error.Custom errors as "haxe.io.Eof" when no explicit length is given See haxe.Http: line https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/Http.hx#L698

Start in haxe.Http at the handling referenced around line 698, then read the surrounding networking API behavior for reads that return ECONNRESET. Reproduce or inspect the no-explicit-length response path and verify that valid data reaches onData rather than triggering onError when the connection closes in this way.

Written by the indexing model from the issue text.