[jira] [Created] (THRIFT-6268) Erlang: the HTTP transport fails with a badmatch on any non-200 reply, offers no https and buffers the body unbounded

["Jens Geyer (Jira)" <ji...@apache.org>]

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)