Serve a response announcing far more than it sends, then close, and
assert the connection process is gone. Fails against stock 4.7.2 with a
conn parked in `closed` holding the bytes it read; passes against the
pinned fix.
Also stop the Hackney tests trusting proxy environment variables.
`no_proxy_env` is not a Hackney option and never was, so a proxy in the
build environment silently turned these into tunnelled requests, which
are never pooled -- exactly the shape several of them mean to exclude.
`proxy: false` is what Hackney actually reads.
That surfaced a matching bug in the reverse proxy client, which treated
`proxy: false` as "a proxy is set" and so declined to mark a pooled
bodyless response as already released.
An unpooled Hackney 4 connection that ends without a reusable socket -- a
body cut short by the peer, a bodyless 204/304, or a failed read -- parks
in its `closed` state forever, holding every refc binary it read.
read_full_body/2 hands back `socket = undefined`, so it never reaches the
reuse check; `closed(enter)` arms a stop timer only for pooled
connections; and an unpooled connection is owned by hackney_conn_sup, so
the owner-DOWN cleanup never fires.
Nothing here can work around it. Since 4.0 Hackney ignores `with_body`
and always returns a fully read binary, so a synchronous request never
yields a handle to close, and the short read still reports {:ok, body}.
Media proxy warming hits this whenever an attachment fetch is cut short
and the outbound proxy is used as a CONNECT tunnel, since tunnels are
never pooled.
Pin the fix, a single commit on top of the 4.7.2 tag, until it ships in a
release. While it is a git dep Hackney drops out of `mix deps.audit` and
`mix hex.outdated`, so this wants moving back to hex promptly.
benoitc/hackney#918, benoitc/hackney#919
Hackney 4 ignores `with_body` and always returns a fully read binary, so
Tesla.Adapter.Hackney never reaches the clause that honours :max_body and
the option became a no-op. Only the gun path still enforced it, through
Pleroma.HTTP.Adapter.Gun. Pleroma.Web.RelMe relies on nothing else, so it
was fetching remote pages unbounded.
Add a middleware that applies the limit for every adapter: reject when
content-length already announces too much, and reject a body that came
back over the limit. Streaming bodies are left alone -- neither adapter
limits those and the caller owns the lease, so failing here on the header
would strand a connection RichMedia is still expected to release.
On the hackney path this bounds what callers are handed rather than peak
memory, since the adapter has read the body before any middleware runs.
