Skip to content

Cap buffered response bodies with max_body_size - #990

Closed
benoitc wants to merge 1 commit into
masterfrom
fix/max-body-size
Closed

benoitc wants to merge 1 commit into
masterfrom
fix/max-body-size

Conversation

@benoitc

@benoitc benoitc commented Oct 25, 2026

Copy link
Copy Markdown
Owner

Buffered body reads on the main API (the default hackney:request body, body/1) appended every chunk with no size limit on HTTP/1.1, HTTP/2 and HTTP/3. A server that keeps sending a body, slowly enough to stay inside recv_timeout, could grow the connection process until the node ran out of memory. Only the direct hackney_h3 API had a cap (GHSA-jq4m).

There is now a max_body_size request option, default 512 MiB (same as hackney_h3), infinity to disable. Past the cap the read returns {error, body_too_large}: HTTP/2 and HTTP/3 cancel only that stream and keep the connection, HTTP/1.1 closes it. Skipping a redirect body now drains without buffering. Streaming and async reads are unchanged.

Behaviour change: buffered downloads above 512 MiB now fail unless max_body_size is raised.

Reported by manus-pi (GHSA-pph4-mwcc-w6v2).

Buffered reads through hackney_conn (the default body read, body/1) had
no size limit on any protocol, so a server sending an endless body could
exhaust memory. Only the direct hackney_h3 API was capped (GHSA-jq4m).
The same 512 MiB default now applies everywhere, per request through
max_body_size. HTTP/2 and HTTP/3 cancel just the stream, HTTP/1.1 closes
the connection. Skipping a redirect body no longer buffers it.
@benoitc

benoitc commented Oct 25, 2026 •

Copy link
Copy Markdown
Owner Author

Closing in favour of #980.

@benoitc benoitc closed this Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant