[
https://issues.apache.org/jira/browse/THRIFT-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18116300#comment-18116300
]
Jens Geyer commented on THRIFT-6283:
------------------------------------
PR #3875 implements this. The description needs two corrections about
{{max_body_size}}:
* The option has not been there since OTP 27. It came with the OTP patch
releases of 2026-09-01: inets 9.3.2.7 (OTP 27.3.4.17), 9.6.2.3 (OTP 28.5.0.6)
and 9.7.2 (OTP 29.0.6). Earlier releases on those lines do not have it, and
neither does any OTP 26 release. Those releases log the option as ignored on
every request, at level notice, so the transport passes it only where the inets
version has it.
* Where httpc has the option, it limits a reply it does not stream only if the
reply declares its length or is chunked. A reply whose body ends when the
connection closes is still read whole.
As suggested, 200 replies are streamed and cancelled once past the limit, on
every OTP release. httpc streams 206 replies in the same way, and its stream
messages do not say which of the two a reply was. So a 206 reply is now read
like a 200 reply.
_Drafted with AI assistance (Claude Opus 5); reviewed and posted by Jens Geyer._
> Erlang: bound the size of a reply the HTTP transport reads
> ----------------------------------------------------------
>
> Key: THRIFT-6283
> URL: https://issues.apache.org/jira/browse/THRIFT-6283
> Project: Thrift
> Issue Type: Sub-task
> Components: Erlang - Library
> Reporter: Jens Geyer
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Split out of THRIFT-6268 (third point). The first point, a failed request, is
> PR #3866.
> {{thrift_http_transport:flush/1}} calls {{httpc:request/4}} in the mode that
> returns the whole reply in memory, with no limit, so the size of a reply is
> whatever the server sends.
> h2. What httpc offers
> * {{max_body_size}} is a documented request option from OTP 27 on. It refuses
> a reply whose {{Content-Length}} exceeds the limit. OTP 25 and 26, both in
> the CI matrix, have no such option.
> * Streaming ({{stream}}) hands over the body in parts, but only for 200 and
> 206 replies; any other reply is still read whole.
> h2. Suggested
> * A limit for the transport, defaulting to 100 MB, the default maximum
> message size the other bindings' TConfiguration uses. It is a new constant
> next to {{DEFAULT_MAX_FRAME_SIZE}} in {{thrift_constants.hrl}}, overridable
> per transport and application-wide the way {{max_frame_size}} is.
> * For 200 replies, stream the body and cancel the request once the limit is
> passed, which works on every supported OTP release. On OTP 27 and later, also
> pass {{max_body_size}}, which covers the replies that are not streamed.
> * Tests: a reply at the limit is read; one byte more is refused before the
> whole reply has been received, with and without {{Content-Length}}.
> _Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens
> Geyer._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
