Request Line Read Error

[beckler]

I recently upgraded a code base to use Bandit, but I immediately ran into issues handling webhooks from Stripe.
While I know this isn't product interaction could be considered irrelevant, I'm unable to reproduce this same behavior with Cowboy, and I'm unable to introspect as to what exactly is going on.

I believe this is ultimately a similar issue to #252, but I'm not sure how to handle this.

Here's the results I get using Bandit mocking a payment_intent.succeeded event:

Same results using Cowboy:

I created a minimal example project that demonstrates this issue. Granted, you'll need a Stripe account and the Stripe CLI tool to setup this test to reproduce it.

If you have any guidance here, let me know! I would love to keep using Bandit, but I don't know if I can move forward with it at the moment.

[mtrudel]

Thanks for the report!

This does look super odd; at first glance it doesn't look too much like #252 to my eye; that issue is about how Bandit handles requests which are obviously not HTTP (ie: intentionally very noisily), whereas this looks like we're just not parsing a (presumably otherwise valid) request properly.

Providing a minimal repro case gets us 95% of the way there; thanks so much for that! I'll look at this first thing in the morning!

[mtrudel]

I've got a repro running locally - I have a good idea what it is but it'll have to wait until morning (UTC-4 (or UTC-5 tomorrow morning!))

[alisinabh]

Sorry to interrupt @mtrudel. I was looking into this and saw your comment after I found the issue!

This actually is a problem with stripity_stripe library. Basically the state showing that the body is completely read is ignored and the keepalive mechanism is not working. I have opened a PR (beam-community/stripity-stripe#821) to address this in stripity-stripe library.

[mtrudel]

That makes perfect sense! I knew the problem had something to do with keep-alive errors (you can tell because Bandit thinks the request line for the next request starts somewhere random in the request body of the previous request), but I'd assumed that the issue was on our side & was planning to see if we'd just gotten our content-length tracking math wrong.

To be honest, I'm pretty sure it would have taken me ages to catch this one; great fix @alisinabh!

I'll leave this issue open to track completion upstream; once @beckler reports a successful fix (or this gets stale) I'll close.

Thanks both for a great & quick resolution to a thorny issue!

[mtrudel]

@beckler looks like the upstream fix is out as 3.1.0 - can you give it a rip and see if it fixes your issue?

[beckler]

Holy shit! I honestly wasn't expecting such a incredible and fast response!
I'm gonna close this, but yes, it absolutely fixed my issue! Thank you both!