-
Notifications
You must be signed in to change notification settings - Fork 528
"Unexpected end of request content" preventing terminating chunk from being sent #1530
Comments
Were you using 1.1? |
Yes:
|
Reading through the other issue, will have an answer soon. |
Self-assigning for investigation. @stephentoub see https://github.com/dotnet/corefx/issues/17330#issuecomment-288168960 |
I thought we'd shipped "FIN as connection reset" in Kestrel 1.1 but we didn't. This was the change: #1218 The current behavior is bad though, in that the server at least do something. Given 1.1 doesn't close the connection after the client FIN, it should attempt to complete the response. This may be a candidate for a patch, but I need to assess how large the change would be. cc @muratg @Eilon |
Filed #1535 to track this for 1.1.2 patch release. |
We're still seeing this error when using Kestrel 1.1.2. Getting a
It;s not something that I've been able to easily reproduce but I'm looking for any advice that anyone has on it. |
@lewislabs The original issue only happened on requests that used the chunked transfer encoding. From your stack trace, I can see that the request includes a Content-Length header (otherwise Kestrel wouldn't be using the Could the client have disconnected mid-request? |
That's certainly possible but it would be unintentional - we're in control of both the client side and server side code. We're seeing this error fairly frequently but it's only for a small fraction of requests. Would a client disconnection be the most likely cause of that stack trace? |
It would definitely show up if the client disconnected before sending the entire request body. You can look for client disconnects in the logs. Looks for messages about ECONNRESET and FIN on the connections where you're seeing that stack trace. Another way to look into what's happening would be to use a tool like Wireshark to see what's getting through the wire. |
@lewislabs @CesarBS Did you solve the issue? I am also having this problem at the moment. I am trying to send large file (20GB) from WebAPI1 to WebAPI2 (hosted locally). When I am sending this file via postman to WebAPI2 it sends whole file. But when I am trying to send the file from WebAPI1 to WebAPI2 it fails (I am able to send files like 7GB though). During sending 20GB file I am receiving error:
|
@maroallegro What do you see on the WebAPI1 side? |
@CesarBS @lewislabs When I run this request as part of WCF contract in WebApi1 i got:
Operation failed always around 2 minutes... Than I tried to send that 20GB file as part of controller method (from WebAPI1) and catched there |
More details here:
https://github.com/dotnet/corefx/issues/17330#issuecomment-288078562
In summary, some clients (e.g. libcurl) stop sending request content if they concurrently receive an error status code in response from the server. If an app on kestrel ignores the request data and immediately sends a response with an error status, the client may as such stop sending the request data, which in turn causes kestrel to fail with a BadHttpRequestException, but it doesn't complete the chunked encoding response by sending a terminating 0-length chunk, nor does it close the connection. As a result, the client is left waiting indefinitely for the remainder of the response that never comes, and effectively deadlocks until timeout.
The text was updated successfully, but these errors were encountered: