[ronleizrowice-ant]

In a TLS-terminated tunnel, an HTTP/1.0 client could lose the end of a long answer. With a Content-Length, curl says (18) transfer closed with N bytes remaining. Without one, the file is short and nothing says so.

In no release: it came with in-process termination (#666). Bun 1.4.3 shows it. Bun 1.4.2, which CI runs, and Node do not.

Why

Under Bun the TLS socket runs on a stream of ours over the tunnel's socket. It has finished once it has written into that stream, long before the client has the bytes.

Bun 1.4.3's HTTP server ends an HTTP/1.0 response with end(), then destroySoon(), which is to destroy the socket once all that was written is out. Here it believes that at once. Traced, for one answer of 5 MiB: 311,738 bytes still queued at the destroy, and 4,915,200 of 5,242,880 delivered. After HTTP/1.1 with Connection: close the server calls end() alone, and the close waits for the flush.

What changes

One line, in serverTlsOn: on that TLS socket, destroySoon() ends it. The tunnel then closes as it does after Connection: close, once the client has everything.

destroy() still cuts at once. The first commit here did it otherwise: it counted every destroy() with no error as an end. That softened the proxy's own back-stops, which destroy a tunnel a second after ending it. With no mux in front (srt proxy), a refused client that never closes was held for 5 to 6 s, where main lets it go after 1 s. The second commit takes that back; the stream is main's again.

What it costs

An HTTP/1.0 client is now treated as one of HTTP/1.1 with Connection: close already is:

	main, HTTP/1.0	main, 1.1 + close; here, both
reads it all, and never closes	let go at once	after 5 to 7 s
reads nothing	let go at once (the data dropped)	after 300 to 365 s

A client that closes when it has the answer, as curl does, sees no difference.

Testing

curl --http1.0 through the public export: 1, 5 and 20 MiB, with and without a Content-Length, 8 at once. Whole answers:

	main	here
Bun 1.4.3	0 of 144	144 of 144
Bun 1.4.2, Node	all	144 of 144 each
HTTP/1.1, Connection: close and keep-alive	all	all

• Refused clients that never read and never close, after a 403 and a 400, with and without the mux, on three builds of Bun: let go when main lets them go (0.2 to 1.3 s).
• Four HTTP/1.0 clients that read nothing, with maxTunnels: 4: a new CONNECT gets 503, then 200 from 303 to 363 s on.
• Four tests, each on a real TLS socket from serverTlsOn, so each runtime brings its own order of events. destroySoon(), with and without an end() first: the client gets every byte. Both fail on main under Bun 1.4.2 too. destroy(), at once and once the socket has finished: cut. The second fails on this PR's first commit.
• 37 network test files on Bun 1.4.2 and 1.4.3: nothing fails that does not on main.

[ig-ant]

LGTM