I think we only used that passthrough workaround with Req.Test.stub, not Req.Test.expect. But yeah, if you’d like to solve this properly and contribute a Req.Test.passthrough/1, a PR is very welcome indeed.
wojtekmach
Hex Core Team
Wojciech
Hi, I noticed that the article “SDKs with Req: Stripe” contains a link to “How we verify webhooks” blog post, but such article doesn’t seem to exist, could you explain why is that the case?
And if you find some time, within the WebHook listener GenServer it would be nice to have second clause of init/1 function changed from:
%{stripe: stripe_cli, forward_to: forward_to}
to:
%{stripe_cli: stripe_cli, forward_to: forward_to}
As the current implementation does not work.
0
dimitarvp
jan-mb-me
Hi @wojtekmach, I only wanted to say thank you.
I just enjoyed the variety of options for retries (Req.Steps — req v0.5.10) to deal with an API that sometimes refuses to accept a newly created access token with “status: 401, message: Invalid or expired” although it accepts it a few milliseconds later.
With Req it was super easy to implement a solution that doesn’t enforce a delay after token creation by default.
Edit:
Thanks to a custom :retry it was very easy to re-implement the default and additionally retry on status 401.
Thanks to a custom :retry_delay the impact on test duration was minimal.
1
Asd
I am sorry to be this kind of guy but it’s been 3 years now. When is 1.0.0 coming up? I remember breaking my production with 0.3.0 update, and then I decided to not use Req until a stable release arrives. Do you have plans for it?
0
wojtekmach
Hex Core Team
arcanemachine
wojtekmach
Hex Core Team
wojtekmach
Hex Core Team
Req v0.6.0 is out:
CHANGELOG
v0.6.0 (2026-06-08)
-
encode_body: Security fix for:form_multipartheader injection
(GHSA-px9f-whj3-246m).The multipart encoder interpolated the per-part
name,filename, and
content_typeinto the part headers without escaping, so an
attacker-controlled value could inject extra headers or smuggle additional
parts into the request. These values are now escaped per RFC 7578 / WHATWG
form-data (", CR, and LF are percent-encoded).Thanks to @PJUllrich for reporting it.
-
decode_body: Drop automatic zip/tar/tgz/gz/zst/csv decoding,
(GHSA-655f-mp8p-96gv).Req previously auto-decoded archive and compressed response bodies (
zip,
tar,tgz,gz,zst, andcsv) based on the server-supplied
content-type, materialising the full decompressed contents in memory with
no size cap. An attacker-controlled (or redirect-reachable) endpoint could
return a tiny “decompression bomb” that expanded to gigabytes and exhausted
the node’s memory.Now only JSON is decoded by default. Other formats are opt-in via the new
:decodersoption, which defaults to[:json, :json_api]. Setting it
replaces the default (include:jsonto keep JSON decoding), andfalse
disables all decoding:# opt into archives (only for endpoints you trust): Req.get!(url, decoders: [:json, :zip])Note: The decoded zip/tar is still list of
{filename :: charlist(), contents :: binary}tuples.
In the future release, this will be list of
{filename :: binary(), contents :: binary()}tuples.While automatic CSV decoding wasn’t a security issue, the behaviour based
on presence/absence ofnimble_csvdependency was suprising. CSV support
is still built-in but need to be enabled withdecoders: [:csv].Custom decoders are supported via
{format, codec}tuples, wherecodecis
a module exportingdecode/1or a 1-arity function returning an:ok/:error
tuple, for example:Req.get!(url, decoders: [:json, ics: &{:ok, ICal.from_ics(&1)}])Thanks to @PJUllrich for reporting it.
11
dimitarvp
Thank you, super reassuring to see you are standing on top of the recent wave of CVEs. Much appreciated!
This is not 100% clear to me: does that mean that decompression bombs are still possible if the user of the library opts in to a certain automatic decoding format? I mean, one cannot do much if somebody targets them with that I suppose, but curios how far does the defense go.
1