NTLM: force the connection to HTTP/1.1

[dscho]

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.

[dscho]

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?

[dscho]

@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 CURLAUTH_NEGOTIATE (some documentation I found suggests so, but I am far from sure)?

[bagder]

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.

[dscho]

Have you verified against a real server that this works?

Yes, I have. That's why it took so long, and that's why I realized in the end that I need to call connclose(); Otherwise, cURL would not try to reconnect but instead reuse the connection (which keeps being HTTP/2).

I too suspect we need the same for negotiate as well

Hmm. My original plan was to intercept HTTP_1_1_REQUIRED and do the same dance in that case. I guess this would still be necessary, and would help Negotiate, without the need to downgrade to HTTP/1.1 pre-emptively (at the cost of an extra round trip if we do need to downgrade to HTTP/1.1).

How does that sound?

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.

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?

[bagder]

My original plan was to intercept HTTP_1_1_REQUIRED and do the same dance in that case. I guess this would still be necessary, and would help Negotiate, without the need to downgrade to HTTP/1.1 pre-emptively (at the cost of an extra round trip if we do need to downgrade to HTTP/1.1).

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 guess this is worth a separate PR, what do you think?

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?

[dscho]

Would you like to see this PR merged first

Yes, please ;-)

[bagder]

Thanks!