Hello, For some time we have investigated an issue that affects curl 7.88.0 until 8.1.0, this issue affects Debian stable as we ship 7.88.1.
The issue is that curl fails to retrieve HEAD on HTTP2 under specific conditions, which we did not manage to identify (so this doesn't happen on any endpoint). Steps to reproduce (using an affected curl release and affected endpoint): curl -I https://h2.git.dgit.debian.org/dgit/info/refs Expected output (obtained on a fixed release, but not the latest one, see below): > HTTP/2 200 > expires: Fri, 01 Jan 1980 00:00:00 GMT > pragma: no-cache > cache-control: no-cache, max-age=0, must-revalidate > x-content-type-options: nosniff > x-frame-options: sameorigin > referrer-policy: no-referrer > x-xss-protection: 1 > permissions-policy: interest-cohort=() > strict-transport-security: max-age=15552000 > vary: Accept-Encoding > x-clacks-overhead: GNU Terry Pratchett > content-type: text/plain > date: Sat, 11 May 2024 19:33:28 GMT > server: Apache Actual output: > curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) And I've just noticed that the latest release (8.7.1) now also outputs the error at the end: > HTTP/2 200 > expires: Fri, 01 Jan 1980 00:00:00 GMT > pragma: no-cache > cache-control: no-cache, max-age=0, must-revalidate > x-content-type-options: nosniff > x-frame-options: sameorigin > referrer-policy: no-referrer > x-xss-protection: 1 > permissions-policy: interest-cohort=() > strict-transport-security: max-age=15552000 > vary: Accept-Encoding > x-clacks-overhead: GNU Terry Pratchett > content-type: text/plain > date: Sat, 11 May 2024 19:33:28 GMT > server: Apache > > curl: (92) HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1) It looks like the regression is partially back, but at least we get the contents with the latest release. Should this also be tracked as a different issue? I did not run bisect to track when the error started showing up again, sorry, I didn't want to delay sending this mail any further. We did a git bisect and identified the commits that introduced and fixed the issue (the first time): Regression commit: https://github.com/curl/curl/commit/8c762f59983a3e9e2b80fdb34aa5e08f1d9a1c7d (curl-7_88_0) Fixing commit: https://github.com/curl/curl/commit/744dcf22fac6cf12a9112df106b61864982afef9 (curl-8_1_0) The problem is the fixing commit is too big, and this type of change is so critical, that I don't feel confident in giving it a try myself. Would it be possible for one of the curl developers to provide a patch that addresses this issue without carrying other changes and lowering the risk of introducing side effects (to be applied on 7.88.1)? I understand it's a lot to ask, so feel free to tell me if that's not possible. Since the regression is partially back on the latest release, you might want to address that first. We decided on the Debian side that we don't want to take that risk ourselves, not being as familiar with the codebase as you are. Debian bug report (NOTE: we disabled http2 for the endpoint listed in the Debian bugreport, the correct one to reproduce is https://h2.git.dgit.debian.org/dgit/info/refs): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037258 I assume this mail is better suited to curl-library rather than distros since I'm asking for help from the curl developers (instead of sharing things with other ditros), but let me know if I should have sent it there. Regards, -- Samuel Henrique <samueloph> -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
