Bug 2139337

Summary: Fall back automagically to HTTP1.1 from HTTP2.0 when performing auth method
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: curlAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Daniel Rusek <drusek>
Severity: high Docs Contact:
Priority: urgent    
Version: 8.7CC: ddallos, fhirtz, fkrska, kdudka
Target Milestone: rcKeywords: Patch, Triaged, ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: curl-7.61.1-27.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2144493 (view as bug list) Environment:
Last Closed: 2023-05-16 09:03:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2144493    

Description Renaud Métrich 2022-11-02 08:42:04 UTC 
Description of problem:

In case NTLM doesn't support HTTP2.0, *curl* should automatically fall back to HTTP1.1.
This magic is performed through implementation of the following commit:

https://github.com/curl/curl/commit/cbea2fd2c74feabeb6f13b3e3df243b225b3b3ab:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
NTLM: force the connection to HTTP/1.1
Since v7.62.0, cURL tries to use HTTP/2 whenever the server announces
the capability. However, NTLM authentication only works with HTTP/1.1,
and will likely remain in that boat (for details, see
https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported).

When we just found out that we want to use NTLM, and when the current
connection runs in HTTP/2 mode, let's force the connection to be closed
and to be re-opened using HTTP/1.1.

Fixes #3341.
Closes #3345
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Unfortunately backporting this commit to RHEL8's curl didn't show any effect.
Since then, I could see a high number of commits related to this area, so it's likely I missed some of them.
Also I don't have the environment to test myself.

I think having this functionality would greatly enhance the user experience, avoiding the need to force using `--http1.1` option to curl.

Version-Release number of selected component (if applicable):

curl-7.61.1-25

How reproducible:

Always on customer system

Steps to Reproduce:
1. Perform a NTML negociation

$ /usr/bin/curl --negotiate -u : https://SERVER > /dev/null
...
curl: (92) HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)

Actual results:


Expected results:

Automatic fallback to HTTP1.1
Comment 18 errata-xmlrpc 2023-05-16 09:03:39 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: curl security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:2963
Comment 19 Daniel Dallos 2025-01-13 23:08:17 UTC 
I'm reopening this bug report because the customer is still seeing the issue:

--------------------------------------------
I've retested using:
# rpm -q curl libcurl
curl-7.61.1-34.el8_10.2.x86_64
libcurl-7.61.1-34.el8_10.2.x86_64

and the issue with POST reported on 2023.01.25 is still present. When executing this command:
$ /bin/curl -H'Content-type: text/plain' --negotiate -u : --data-binary "@/tmp/hostcert-RztIkM5UoQ/host.csr" --output /tmp/hostcert-RztIkM5UoQ/host.p7b --trace /var/tmp/curl.trace -s -S -w "%{http_code}" https://$SIGNING_SERVICE
the trace file still ends with this without sending an HTTP/1.1 request:

== Info: HTTP/2 stream 0 was not closed cleanly: HTTP_1_1_REQUIRED (err 13)
== Info: Forcing HTTP/1.1 for NTLM== Info: stopped the pause stream!
== Info: Connection #0 to host <elided> left intact
Comment 20 Daniel Dallos 2025-01-13 23:20:15 UTC 
Continuing in:

https://issues.redhat.com/browse/RHEL-73788