Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
NTLM: force the connection to HTTP/1.1 #3345
Conversation
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. This fixes #3341. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
TBH I am not quite sure why test 408 fails in Travis, it looks like it times out? This cannot be caused by the changes in this PR, can it? |
|
@bagder is this approach okay? Can I set the HTTP version this way or do you insist on a flag (and if so, which struct should hold it)? Do we need the same for |
|
I think this looks clean and understandable when reading the code which is all I need =). Have you verified against a real server that this works? I too suspect we need the same for negotiate as well, since it can basically imply NTLM (but not always) - but I''m not at all an expert on negotiate and I believe we have more of this style of issues with negotiate in the code: that we treat NTLM as the connection-based authentication scheme. I think I'm suggesting that we can leave negotiate out of this fix for now until we understand that side of the planet a little better. |
Yes, I have. That's why it took so long, and that's why I realized in the end that I need to call
Hmm. My original plan was to intercept How does that sound?
Sure, we could do that, too. But I already have the setup to test (actually, my excellent colleague @jeschu1 has this setup and lets me use it). So I will probably work on that, but I guess this is worth a separate PR, what do you think? |
I think that's a really good idea, as that would then also cover other potential cases where this is returned that we haven't yet considered or experienced!
I agree. Would you like to see this PR merged first/independently or would you rather wait and see where this next PR ends up? |
Yes, please ;-) |
|
Thanks! |
NTLM is incompatible with HTTP/2, and most (or all) of Kerberos, too. In such cases, it is a problem that cURL v7.62.0 changed the default to use HTTP/2 for https:// connections whenever servers indicate support for it. This is a backport of curl/curl#3345 and curl/curl#3349, so that Git for Windows v2.20.0 will have those fixes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 curl#3341. Closes curl#3345 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This addresses #3341.
I took a slightly different approach than suggested in that ticket: instead of trying NTLM via HTTP/2 and then imitating a HTTP redirect when we get
HTTP_1_1_REQUIRED, this PR introduces the change where we detect that situation preemptively, i.e. before trying NTLM we already ensure that we're on HTTP/1.1.