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 upNTLM: 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>
dscho commentedDec 6, 2018
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.