runtime: [release/2.1] Expect100Continue with Windows auth and request body > 1024 bytes fails

I’m a customer, new to this issue. I updated my application dependencies (core 2.2 and wcf 4.5.3) today and promptly crashed my application. I’m here to vote for prioritization. Any thoughts on a timeline to fix? Thanks.

Customer here, I would love to see this issue resolved. When starting a new project we shouldn’t have to check if every workaround is still required. This issue is still very much there and open for quite sometime now and needs to be resolved 😃

Fix for release/2.1 checked in with PR dotnet/corefx#39341

Fixed in master for .NET Core 3.0 with PR dotnet/corefx#38744

Re-opening for release/2.1 and release/2.2 consideration.

Disabling 100-Continue does avoid the issue but that’s not something a developer can do very easily. When 100-Continue support was added to HttpClient, I modified WCF to match the behavior we have on .NET Framework. We don’t have any API to change that behavior as on .NET Framework you can do this using ServicePointManager so WCF doesn’t have any API’s exposed to modify this behavior.
This is still blocking partner as our customers are continuing to have problems with this. Look at the issue in WCF where we are tracking this (dotnet/wcf#2923) to see how many people have problem.
On .NET Framework it does send the request twice on the authentication handshake so that behavior is acceptable to exist for fixing in 2.1+ (as 2.1 is a LTS so needs the functional break fixed there). I see my suggestion of the added optimization to remove the second send as being an improvement beyond what .NET Framework does so that’s fine to be in 3.0. I’m not looking to retroactively add features 😄 .

@geoffkizer, the current solution means that you can’t use use NTLM authentication with the Expect header. It simply can’t work as it abandons the request and throws an HttpRequestException at the caller. I ran some experiments and recorded what HttpWebRequest does on the .Net Framework so I’ll give a quick overview here.

1. –> Client sends headers including an Expect: 100-continue header
2. <-- Server responds with 401 status and WWW-Authenticate: NTLM header (no blob)
3. –> Client sends the request body (to keep socket open)
4. –> Client sends request headers including Authorization header with initial NTLM authorization blob, no expect header and Content-Length: 0 header (no expect header because no request body).
5. <-- Server responds with a 401 status and a WWW-Authenticate header with NTLM response blob
6. –> Client sends request headers including Authorization header with final NTLM authorization blob, the correct Content-Length header and an Expect: 100-continue header
7. <-- Server responds with a 100 status
8. –> Client sends request body
9. <-- Server responds with final response status, headers and body

This is the minimum that should be done. I believe that this can be optimized further. I suspect in step 3 the client could abandon the socket as there’s no state information about the authentication that has been transmitted yet. This is the general idea that the current code attempts to do. But the current implementation then throws an HttpRequestException at the caller and there’s no way to complete the request. Instead it should close the connection, not throw and create a new connection instead. Although the current limit of 1024 is too small as that is less than a single ethernet frame payload. Ideally the RTT would be queried from the OS and a heuristic used to work out which approach would be quicker but the System.Net.Socket abstraction is too far removed from the OS to query this information.

Additionally, when PreAuthenticate has been enabled and a credentials cache is used which only contains NTLM credentials, the first request can probably be skipped and can jump straight to step 4 as the server doesn’t provide any challenge data in the initial authentication challenge. That would avoid sending the request body completely until after the authentication is completed. There is a risk that some servers could initialize some state when replying with the empty NTLM challenge, but that’s easily tested and could be turned off by not using setting PreAuthenticate to true if some implementation failed with this optimization.

@mconnew, I’m not entirely sure what you want us to do in this scenario. When we get an early response with Expect: 100-continue, we either need to (a) finish sending the request body, so we can keep the connection alive, or (b) close the connection and stop sending the request body.

Removing label until this is ready for big shiproom.