On Saturday, June 10 2023, Samuel Henrique wrote: > Hello, > > I'm not able to reproduce the issue on Bookworm with a HTTP2 localhost > apache server. [...]
Hey, I was able to find another URL that triggers the same issue. This one: https://chinarising.puntopress.com/wp-content/uploads/2023/04/Press-TV-KSA-Iran.mp3 (I found it while reading https://github.com/curl/curl/issues/9526) Annoyingly, I still can't determine how to reliably reproduce the problem by configuring a local webserver... Anyway, this new URL allowed me to continue the investigation, and I found that the following commit seems to have introduced the problem: 8c762f59983a3e9e2b80fdb34aa5e08f1d9a1c7d is the first bad commit commit 8c762f59983a3e9e2b80fdb34aa5e08f1d9a1c7d Author: Stefan Eissing <ste...@eissing.org> Date: Wed Feb 8 15:56:57 2023 +0100 http2: minor buffer and error path fixes It's a much smaller commit, and if we focus only on the lib/http2.c changes, we notice that they are directly related to the handling HTTP2 stream closures. By comparing the two commits (the one that introduces the failure and the other that fixes it), it's pretty hard to say what exactly could be the fix here because the code changed so much between them. With my mad scientist hat on, I decided to experiment with something I'd noticed: the "bad" commit indiscriminately treats "stream->reset" and "stream->error" the same way, while the "good" commit doesn't. I applied the following change to the code: diff --git a/lib/http2.c b/lib/http2.c index d5eed385e..2dc8ee348 100644 --- a/lib/http2.c +++ b/lib/http2.c @@ -1919,7 +1919,7 @@ static ssize_t cf_h2_recv(struct Curl_cfilter *cf, struct Curl_easy *data, Curl_expire(data, 0, EXPIRE_RUN_NOW); } else if(stream->closed) { - if(stream->reset || stream->error) { + if(stream->reset) { nread = http2_handle_stream_close(cf, data, stream, err); goto out; } ... and it seemed to "work". Of course, I don't claim the change above to be correct, but it does seem to confirm the suspicion that "stream->error" shouldn't be handled as a stream closure. Things to investigate: - Why are we getting "stream->error" here? Maybe "--trace" can help us. - How to reliably reproduce the problem locally? It'd be really nice to have a testcase for this. Ah, I forgot to mention: initially I had the suspicion that this might be related to the openssl 3 transition, but I was able to reproduce the problem using bullseye, so I think that proves my hypothesis wrong. It's late here now so I'm calling it "a day", but I'll try to get back to this investigation in the following days. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
