Jens Geyer created THRIFT-6268:
----------------------------------
Summary: Erlang: the HTTP transport fails with a badmatch on any
non-200 reply, offers no https and buffers the body unbounded
Key: THRIFT-6268
URL: https://issues.apache.org/jira/browse/THRIFT-6268
Project: Thrift
Issue Type: Bug
Components: Erlang - Library
Reporter: Jens Geyer
{{lib/erl/src/thrift_http_transport.erl}}, in the flush path ({{:96}}):
{code:erlang}
{ok, {{_Version, 200, _ReasonPhrase}, _Headers, Body}} =
httpc:request(...)
{code}
Three things follow from that line and its surroundings:
* *Any reply that is not 200 is a badmatch.* A 404, a 500 or a redirect from a
proxy crashes the calling process with {{{badmatch, {ok, {{"HTTP/1.1", 500,
...}}, ...}}}} instead of producing a {{TTransportException}} the caller can
handle. The status is available and is simply not inspected.
* *There is no {{https}} option.* The transport builds its URL for {{http}}
only, so the client cannot talk to a TLS endpoint without being rewritten.
* *The response body is buffered without a bound.* {{httpc:request/4}} is
called in the mode that returns the whole body in memory, with no
{{max_body_size}} or streaming, so the size of a reply is whatever the server
sends.
h2. Suggested fix
Match the status separately and turn a non-2xx reply into a
{{TTransportException}}; allow {{https}} as a scheme option; and either stream
the body or apply a configurable ceiling to it.
The three could be split into separate issues if that suits review better --
they are filed together because they are all in the same twenty lines.
_Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens Geyer._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
