Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Request for help on backporting a fix for HTTP2 HEAD (regression possibly still there on 8.7.1)
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Samuel Henrique via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 13 May 2024 21:31:26 +0100
Hello Jim,
> > 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
>
> Not saying I have the time, but could you be able to provide some details of
> curl build in debian specifically I would want to know about (might be
> obvious for some, but not everyone) or if you have links about:
I should have mentioned that we bisected using plain upstream code with
openssl, without any of the Debian patches applied (as we were trying to
rule-out Debian-specific issues).
I believe this would be reproducible under any environment.
The build flags I tend to use when bisecting are:
./configure --with-nghttp2 \
--with-openssl \
--with-ca-path=/etc/ssl/certs \
--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \
--prefix $HOME/curl/install
This should be enough to be able to reproduce.
But still, I'll also reply to to the questions below in case they're useful at
some point in time:
> * where to pull the debian curl code
The code we use for stable:
https://salsa.debian.org/debian/curl/-/tree/debian/bookworm?ref_type=heads
> * what config flags (and deps) are used
Build flags:
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L12-17
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L23
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L85-87
> * any special handling
I don't think there's anything else worth pointing out other than the build
flags listed.
> * how to test (in debian context)
As I mentioned above, we were not testing the Debian package, but the upstream
code directly.
Any build of that affected version range (7.88.0 until 8.1.0) should trigger
the issue when hitting certain endpoints (not all will trigger this).
> Somewhat related (and naive distro question) .. what are the debian pov
> pros/cons of patching this versus the pros/cons of just going to latest and
> greatest (or perhaps a security patched v8.1.0) ?
We do provide newer versions of curl through the backports mechanism
(https://backports.debian.org/), but we don't promise the same stability and
support as with the regular stable repositories.
Users tend to prefer to stick to the versions they certified their
infrastructure with, so as to avoid unknown regressions caused by new bugs or
new limits introduced, they would not be happy with us bumping to the newer
release and possibly breaking their services.
The rule of thumb is that they can use backports or update to a newer release
of the distro to get the newer version (in this case, Debian testing) if
bumping versions is not a risk for them.
Thank you!
Date: Mon, 13 May 2024 21:31:26 +0100
Hello Jim,
> > 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
>
> Not saying I have the time, but could you be able to provide some details of
> curl build in debian specifically I would want to know about (might be
> obvious for some, but not everyone) or if you have links about:
I should have mentioned that we bisected using plain upstream code with
openssl, without any of the Debian patches applied (as we were trying to
rule-out Debian-specific issues).
I believe this would be reproducible under any environment.
The build flags I tend to use when bisecting are:
./configure --with-nghttp2 \
--with-openssl \
--with-ca-path=/etc/ssl/certs \
--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \
--prefix $HOME/curl/install
This should be enough to be able to reproduce.
But still, I'll also reply to to the questions below in case they're useful at
some point in time:
> * where to pull the debian curl code
The code we use for stable:
https://salsa.debian.org/debian/curl/-/tree/debian/bookworm?ref_type=heads
> * what config flags (and deps) are used
Build flags:
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L12-17
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L23
https://salsa.debian.org/debian/curl/-/blob/28044b0273c1e8e6b334a3b237bd2c19c86b54ac/debian/rules#L85-87
> * any special handling
I don't think there's anything else worth pointing out other than the build
flags listed.
> * how to test (in debian context)
As I mentioned above, we were not testing the Debian package, but the upstream
code directly.
Any build of that affected version range (7.88.0 until 8.1.0) should trigger
the issue when hitting certain endpoints (not all will trigger this).
> Somewhat related (and naive distro question) .. what are the debian pov
> pros/cons of patching this versus the pros/cons of just going to latest and
> greatest (or perhaps a security patched v8.1.0) ?
We do provide newer versions of curl through the backports mechanism
(https://backports.debian.org/), but we don't promise the same stability and
support as with the regular stable repositories.
Users tend to prefer to stick to the versions they certified their
infrastructure with, so as to avoid unknown regressions caused by new bugs or
new limits introduced, they would not be happy with us bumping to the newer
release and possibly breaking their services.
The rule of thumb is that they can use backports or update to a newer release
of the distro to get the newer version (in this case, Debian testing) if
bumping versions is not a risk for them.
Thank you!
-- Samuel Henrique <samueloph> -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-05-13