docs(http): update hackney comments for 4.9

lib/pleroma/tesla/middleware/max_body.ex

@@ -7,16 +7,14 @@ defmodule Pleroma.Tesla.Middleware.MaxBody do
   Enforces the `:max_body` adapter option for every adapter.
 
   `Pleroma.HTTP.Adapter.Gun` applies the limit as it accumulates a `:plain`
-  body, so an oversized response is abandoned mid-transfer. Hackney cannot:
-  since 4.0 it ignores `with_body` and always hands back a fully read binary
-  (`hackney:request/5`), so `Tesla.Adapter.Hackney` never takes the branch that
-  would honour `:max_body`. Without this middleware the option is silently
-  unenforced there.
+  body, so an oversized response is abandoned mid-transfer. Since 4.9 Hackney
+  does the same with the `max_body` request option. Before that it ignored
+  `with_body` and always handed back a fully read binary (`hackney:request/5`),
+  so `Tesla.Adapter.Hackney` never took the branch that would honour
+  `:max_body`.
 
-  The check therefore bounds what callers are handed, and refuses up front when
-  `content-length` already announces too much. It cannot bound peak memory on
-  the hackney path, because the adapter has read the body before any middleware
-  runs.
+  The check bounds what callers are handed, whatever the adapter does, and
+  refuses up front when `content-length` already announces too much.
 
   Streaming bodies are left alone: neither adapter limits those, and the caller
   that owns the stream is the one that has to drain and release it.

test/pleroma/http/hackney_conn_leak_test.exs

@@ -14,16 +14,15 @@
 #
 # Pleroma cannot work around this: since 4.0 Hackney ignores `with_body` and
 # always returns a fully read binary, so a synchronous request never yields a
-# handle to close. Up to 4.8 a truncated read also reported `{:ok, body}`;
-# since 4.9 it is `{:error, {:closed, partial_body}}`.
+# handle to close. Up to 4.8.2 a truncated read also reported `{:ok, body}`;
+# since 4.8.3 it is `{:error, {:closed, partial_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. That is how it was found.
 #
-# Fixed upstream by https://github.com/benoitc/hackney/pull/919; mix.exs pins
-# that commit until it lands in a release. Should this start failing, the pin
-# has been moved to a version without the fix.
+# Fixed upstream by https://github.com/benoitc/hackney/pull/919. Should this
+# start failing, mix.exs has moved to a Hackney version without the fix.
 #
 # https://github.com/benoitc/hackney/issues/918
 defmodule Pleroma.HTTP.HackneyConnLeakTest do

test/pleroma/http/hackney_max_body_regression_test.exs

@@ -44,8 +44,8 @@ defmodule Pleroma.HTTP.HackneyMaxBodyRegressionTest do
              request("#{server.base_url}/big", max_body: 1024)
   end
 
-  # Without a Content-Length the header pre-check cannot fire, so this is the
-  # case that proves hackney's fully-read binary is measured.
+  # Without a Content-Length the header pre-check cannot fire, so only a size
+  # check on the body can refuse this.
   test "a chunked body over max_body is refused on size alone", %{server: server} do
     assert {:error, :body_too_large} =
              request("#{server.base_url}/chunked", max_body: 1024)
@@ -58,7 +58,7 @@ defmodule Pleroma.HTTP.HackneyMaxBodyRegressionTest do
     assert byte_size(body) == @body_bytes
   end
 
-  test "without max_body the body is returned whatever its size", %{server: server} do
+  test "without max_body the body is returned", %{server: server} do
     assert {:ok, %Tesla.Env{status: 200, body: body}} = request("#{server.base_url}/big", [])
     assert byte_size(body) == @body_bytes
   end