Request for help on backporting a fix for HTTP2 HEAD (regression possibly still there on 8.7.1)

From: Samuel Henrique via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 11 May 2024 20:57:32 +0100

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

Received on 2024-05-11