Open stap123 opened 5 years ago
halter73
commented
5 years ago Happy to provide more information if it is a genuine bug rather than something I'm doing wrong, just let me know.
This is expected behavior when a client disconnects in the middle of uploading a request body.
We might want to have MVC swallow these exceptions so we don't get scary logs from the server when this happens. @Tratcher
Tratcher
commented
5 years ago @rynowak thinks we should change model binding such that request body read errors are converted to model state errors. This includes client disconnects and form parsing errors.
Note this one is a little different, it happens in AntiForgery but we should still make sure it gets handled at that layer.
rynowak
commented
5 years ago Agreed, this kind of issue should not result in a 500.
@halter73 @Tratcher - is there a clear way to detect an IO failure due to connection loss? There's going to be a try/catch somewhere in our code and I'm wondering what we're going to be catching.
Tratcher
commented
5 years ago They should be IOExceptions 😁, or at least derived from IOExceptions.
With the form reader in the middle it might be a bit trickier, it may wrap the IOExceptions.
halter73
commented
5 years ago @Tratcher is right. Technically it's a Microsoft.AspNetCore.Connections.ConnectionResetException, but I'd catch any IOException.
liuliang-wt
commented
4 years ago I also run into this problem , .netcore 3.1 running on IIS, is there a way I can catch this ConnectionReset exceptions in current version, or I have to wait for the 5.0.0
halter73
commented
4 years ago @luisquintanilla If you want to catch this, you can catch IOException because ConnectionResetException is an IOException. That said, ConnectionResetException has always been public. What are you waiting for in 5.0?
liuliang-wt
commented
4 years ago @halter73 OK, I saw you add it to milestones 5.0.0, I thought I have to wait until then ....
Tratcher
commented
4 years ago @liuliang-wt the plan for 5.0 is to have MVC catch these errors from the form reader so they don't show up in the logs anymore.
mlsomers
commented
4 years ago I think this isn't just a co-incident but I'm seeing these errors when someone tries to log in to my website (using Edge). There will be about 20 of these exceptions all within the same second, before the login is successful (the login does take a while, but is finally successful). It's not easy to reproduce, the site must be running for quite a while before this happens.
Here's my stacktrace (from the EventLog):
Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x80070040): The specified network name is no longer available. (0x80070040)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.ReadAsync(CancellationToken token)
at System.IO.Pipelines.Pipe.DefaultPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at System.IO.Pipelines.StreamPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgeryTokenStore.GetRequestTokensAsync(HttpContext httpContext)
at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.ValidateRequestAsync(HttpContext httpContext)
at Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.ValidateAntiforgeryTokenAuthorizationFilter.OnAuthorizationAsync(AuthorizationFilterContext context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)It may be a issue with Edge though, so I'll try to get them to use another browser and see if these still occur.
Tratcher
commented
4 years ago What kind of auth? For something like windows auth that would almost make sense, its connection based so connections with the wrong credentials would need to be closed by the client.
mlsomers
commented
4 years ago Not sure but I guess this is called Forms Authentication? My Configure just has app.UseAuthentication();. It's supposed to send username and password in a Post request to Identity/Account/Login which sets a cookie.
Maybe I have some setting that would have the client attempt windows authentication? What should I be looking for? And why would it not be happening consistently (it never happens in development, only after some time in production, and not always).
Tratcher
commented
4 years ago Nevermind, Forms/Identity are unrelated to windows auth.
rocklan
commented
4 years ago I am getting these errors too in my logs. Is there a workaround for this?
SidShetye
commented
4 years ago Just saw this around midnight PST. ASP.NET Core 3.1 on Azure App Service (Windows instances, Linux containers haven't exhibited this - yet?). Procedurally, this is happening during a custom ASP.NET machine-machine authentication and our last record shows this happening during a sudden 40x burst of requests. Everything settled down within 6-7 minutes.
Here is one of the exception:
Microsoft.AspNetCore.Connections.ConnectionResetException:
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult (Microsoft.AspNetCore.Server.IIS, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext+<ReadBody>d__337.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException (System.IO.Pipelines, Version=4.0.2.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at System.IO.Pipelines.Pipe.GetReadResult (System.IO.Pipelines, Version=4.0.2.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at System.IO.Pipelines.Pipe.GetReadAsyncResult (System.IO.Pipelines, Version=4.0.2.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext+<ReadAsync>d__334.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream+<ReadAsyncInternal>d__11.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream+<ReadAsync>d__36.MoveNext (Microsoft.AspNetCore.WebUtilities, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.IO.Stream+<CopyToAsyncInternal>d__30.MoveNext (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
<snip>
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
<snip>
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker+<<InvokeFilterPipelineAsync>g__Awaited|19_0>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker+<<InvokeAsync>g__Logged|17_1>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Routing.EndpointMiddleware+<<Invoke>g__AwaitRequestTask|6_0>d.MoveNext (Microsoft.AspNetCore.Routing, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware+<Invoke>d__5.MoveNext (Microsoft.AspNetCore.Authorization.Policy, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware+<Invoke>d__6.MoveNext (Microsoft.AspNetCore.Authentication, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
<snip>
Inner exception System.Runtime.InteropServices.COMException handled at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult:In my case these errors were related to deadlocks. During login (amongst other places) I create or update a "last seen" record. After disallowing page locks on that table these issues went away. We would only notice this during login since the other failing ajax calls did not notify the user of any failures.
Unfortunately this means that the deadlock-victim-exception was eaten up somewhere in the process and I ended up only getting this generic COMException (0x80070040): The specified network name is no longer available. That should be fixed!
If there is an InnerException on the COMException, it should be logged as well. (I don't know for sure because I did not reproduce this while debugging)
joch0a
commented
4 years ago I'm getting this error quite frequently when a client disconnects. There are any plans on catching this exception on the next releases or should I catch this exception? Thanks!
halter73
commented
4 years ago @JoseOchoaITH There are no plans to internally catch ConnectionResetExceptions thrown while reading the request body. To the contrary, we go out of our way to throw ConnectionResetExceptions so truncated requested bodies caused by early client disconnects are not mistaken for complete request bodies.
If the goal is to clean up the error logs that result when a client disconnects mid-request-body, then you should catch the exception yourself. ConnectionResetException is an IOException, so I recommend catching IOExceptions. Handling all IOExceptions in the same manner works well for most apps.
Tratcher
commented
4 years ago There are proposals for some components that read the request body like MVC model binding to catch these exceptions and short circuit with a 400 response. That should help limit some if the log noise.
cgountanis
commented
4 years ago Any recommendation on how to best error handle this, ends up from my controller which has try/catch to the last middleware which is not the most obvious place for custom error handling IMO.
ItWorksOnMyMachine
commented
4 years ago I don't know if my issue is related to ModelBinding or not, but I've been seeing these errors since January and still haven't found a resolution. We were running Asp.Net Core 2.2 and everything was fine, not a single one of these error. We rolled out and update that included an upgrade to Asp.Net Core 3, and we are no on 3.1. Literally the following day, 8 of these errors. On a monthly bases, we see 150 - 200 of these errors. That's with thousands of unique users where at any given time there are 100+ active unique sessions. These errors only happen on POST, but they happen fairly equally across our user-base. No pattern there.
Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x80070040): The specified network name is no longer available. (0x80070040)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory1 memory, CancellationToken cancellationToken) at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.BufferedReadStream.EnsureBufferedAsync(Int32 minCount, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.MultipartReaderStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool1 bytePool, Nullable1 limit, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList1 factories) at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.TryCreateAsync(ActionContext actionContext, IList1 factories)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>cDisplayClass0_0.<
Tratcher
commented
4 years ago Were you using IIS in-proc in 2.2? This might just be a change in how the error surfaces due to changing defaults like in-proc vs out-of-proc. But yes, this is in the category of errors that model binding should catch (it derives from IOException).
ItWorksOnMyMachine
commented
4 years ago I wish I had a better answer than "I'm not quite sure" but that's it. We never specified, and were too ignorant at the time to really understand that we should know, but I believe the default was out-of-proc for 2.2, so that's why I say I'm not quite sure. But I believe we were out of proc. I'm actually moving it back to out-of-proc now just to see if that resolves the issue. I've seen other anecdotal evidence that suggests it is an issue with not enough stack space. We do have logs of request headers when this happens, and the ones that aren't legitimate client disconnects, all have large content-length headers.
Tratcher
commented
4 years ago Stack space is unrelated to request body sizes, and you'd get a StackOverflowException if that were the issue.
Can you share more about the requests you saw that weren't legitimate disconnects? How could you tell?
ItWorksOnMyMachine
commented
4 years ago I suppose I should be more clear. Some of the disconnects we can prove users navigated away from the page. However, the ones we consider not "legitimate" disconnects may still be disconnects at the client, but not due to an intentional action by the user. In these cases, the user clicks a button to perform an action like upload a file, save the state of the page, etc. We have a standard object that handles the low-level Http Fetch operation and upon completion of the fetch promise, we parse the result and if it's not a successful result, we present the user with an error dialog. These specific results return a "Network request failed" error. We get a screenshot of the error box from our users clearly showing they didn't navigate away from the page. Now, that doesn't mean that a firewall or something didn't terminate the request. So, I don't know for sure that it's not a "legitimate" client disconnect, just that it's not a user-initiated disconnect.
Prior to the upgrade to 3+, we never got reports like this from users. So while it might just be that an exception is presenting itself differently due to being in-proc instead of out-of-proc, we never received reports of errors happening randomly like this previously. And, in most cases, if the user simply dismissed the error dialog and clicks the "Save" button again, it frequently works just fine.
Tratcher
commented
4 years ago How large is the content-length?
ItWorksOnMyMachine
commented
4 years ago We have 1,351 of these exceptions where we think they happened without an intentional navigation event. They range anywhere from 2 bytes to 443 MB! We have some file upload endpoints that allow for large files. We explicitly set the size limits larger on those, so they should work, and usually do. The average size of the failed request is about 10 MB though. This has happened across 51 unique api endpoints and only a couple of those accept files. 1,351 errors is a lot, but in context, this website has served up nearly 35 million api requests so far this year.
Eternal21
commented
3 years ago We started seeing bursts of these errors after migration from out-of-process 2.1 to in-process 3.1. May be potentially related to this: https://github.com/dotnet/aspnetcore/issues/6415
jbeacham
commented
2 years ago Is there any answer to this? We see hundreds of these per day on .NET 6. We saw them on .NET Core 3.1 as well. Can't seem to find any resolution anywhere.
Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x800704CD): An operation was attempted on a nonexistent network connection. (0x800704CD)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at System.IO.Pipelines.Pipe.DefaultPipeReader.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.Formatters.NewtonsoftJsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)
at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value, Object container)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|26_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)I think this problem just kind of went away but I can't remember how to help you 🙏
ISkomorokh
commented
2 years ago We keep seeing very similar problem :( Azure App Service, .net core 5
Microsoft.AspNetCore.Connections.ConnectionResetException:
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult (Microsoft.AspNetCore.Server.IIS, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext+<ReadBody>d__369.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException (System.IO.Pipelines, Version=5.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at System.IO.Pipelines.Pipe.GetReadResult (System.IO.Pipelines, Version=5.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at System.IO.Pipelines.Pipe.GetReadAsyncResult (System.IO.Pipelines, Version=5.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext+<ReadAsync>d__365.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream+<ReadAsyncInternal>d__10.MoveNext (Microsoft.AspNetCore.Server.IIS, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Text.Json.JsonSerializer+<ReadAsync>d__20`1.MoveNext (System.Text.Json, Version=5.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonInputFormatter+<ReadRequestBodyAsync>d__7.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Formatters.SystemTextJsonInputFormatter+<ReadRequestBodyAsync>d__7.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder+<BindModelAsync>d__11.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder+<BindModelAsync>d__8.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider+<>c__DisplayClass0_0+<<CreateBinderDelegate>g__Bind|0>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker+<<InvokeInnerFilterAsync>g__Awaited|13_0>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker+<<InvokeFilterPipelineAsync>g__Awaited|19_0>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker+<<InvokeAsync>g__Logged|17_1>d.MoveNext (Microsoft.AspNetCore.Mvc.Core, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Routing.EndpointMiddleware+<<Invoke>g__AwaitRequestTask|6_0>d.MoveNext (Microsoft.AspNetCore.Routing, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.Azure.AppConfiguration.AspNetCore.AzureAppConfigurationRefreshMiddleware+<InvokeAsync>d__5.MoveNext (Microsoft.Azure.AppConfiguration.AspNetCore, Version=4.4.0.0, Culture=neutral, PublicKeyToken=69dad7634abb75e4)
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware+<<Invoke>g__Awaited|6_0>d.MoveNext (Microsoft.AspNetCore.Diagnostics, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60)
Inner exception System.Runtime.InteropServices.COMException handled at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult:
fabiomaulo
commented
2 years ago A lot of same exceptions uploading photos (up to 4MB). The timeout of the request, on the browser side, is set to 120". So far in NET3.1 but we are moving to NET6. The exception is logged by our exceptions-logger-middleware and even registered in the event-log (Azure web-app windows). Never saw these exceptions with NET-FW. The event-log look like:
Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
RequestId: 800084e7-0001-a000-b63f-84710c7967bb
RequestPath: /myspace/publicaciones/publicacionuploadtempphotos
SpanId: |f53fc688-4418137b07d6d3dc.
TraceId: f53fc688-4418137b07d6d3dc
ParentId:
An unhandled exception has occurred while executing the request.
Exception:
Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x800704CD): An operation was attempted on a nonexistent network connection. (0x800704CD)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at System.IO.Pipelines.Pipe.DefaultPipeReader.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.BufferedReadStream.EnsureBufferedAsync(Int32 minCount, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.MultipartReaderStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.TryCreateAsync(ActionContext actionContext, IList`1 factories)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ExceptionContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Localization.RequestLocalizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
at xxxx.LogExceptionsMiddleware.Invoke(HttpContext httpContext) in C:\xxxx\LogExceptionsMiddleware.cs:line 48
at xxxx.LogExceptionsMiddleware.Invoke(HttpContext httpContext) in C:\xxxx\LogExceptionsMiddleware.cs:line 48
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)Legend xxxx = our silli stuff
ghost
commented
2 years ago Thanks for contacting us.
We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
kiranbhadani
commented
2 years ago I am also facing lot of these exception, is there any way to catch those and suppress it
dxynnez
commented
1 year ago I am trying to figure out why IIS would throw the ConnectionResetException in such case but not the more well-known OperationCanceledException for request aborted by the client.
I see that in #46330 @Tratcher suggested to honor the IOException the same way as the OperationCanceledException but it wasn't accepted. Does that mean in .Net 8 the IOException would no longer be thrown by the related components in case of a client abortion?
Is the logic
if ((ex is OperationCanceledException || ex is IOException) && context.RequestAborted.IsCancellationRequested)
robust enough for filtering the client initiated abortion in .net 6?
Any guidance would be greatly appreciated.
dxynnez
commented
1 year ago @Tratcher , is this something you can help to clarify? Thanks so much!
Tratcher
commented
1 year ago That logic check could still trigger if the server initiated the abort.
What do you plan to do with this check?
dxynnez
commented
1 year ago @Tratcher we want to filter out all the 500s caused by client abort.
In what case the server initiated abort would also signal the context.RequestAborted.IsCancellationRequested?
Tratcher
commented
1 year ago E.g. HttpContext.Abort() would also trigger that from the server side. But if you only want to filter out exceptions, anywhere you're calling Abort should already have its own logs.
dxynnez
commented
1 year ago E.g. HttpContext.Abort() would also trigger that from the server side. But if you only want to filter out exceptions, anywhere you're calling Abort should already have its own logs.
@Tratcher Thanks for the information! Our application would never call the HttpContext.Abort. Can I assume that the framework would never call it either, or any other API that would result in a server initiated abort?
Tratcher
commented
1 year ago Nothing that I'm aware of.
vmachacek
commented
1 year ago I am also facing lot of these exceptions
Ben-krebs
commented
1 year ago This would be great to have a solution to. It our case it is not causing any issues for our users, but is filling our logs with exceptions, which makes it hard to see if there are actual issues
naviln
commented
12 months ago Hi guys,
I have been facing this issue intermittently, mostly with users located in Phillipines.
Here is the stack trace:
Exception:Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x800704CD): An operation was attempted on a nonexistent network connection. (0x800704CD)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.ReadAsync(CancellationToken token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at System.IO.StreamReader.ReadBufferAsync(CancellationToken cancellationToken)
at System.IO.StreamReader.ReadToEndAsyncInternal(CancellationToken cancellationToken)This is from my web app running on Azure, with TargetFramework of net7.0. This error originates from a POST endpoint method, which is used to save data (Base64 strings) from inside the http body into our database. The users on the website recieve a HTTP 408 error code (Timeout).
Does anybody have any suggestions, workarounds or fixes available?
EDIT: My Azure web app is running in Australia East (Sydney), and I was able to reproduce the issue by using a VPN and tunnelling through to Vietnam, and making the same POST requests from there. It happens on a random basis - some requests will take 15-40 seconds and pass, and others (for the same file) will fail within 10-14 seconds with the same disconnect error. 😕 Is it related to low transfer rates? Routing from Asia?
naviln
commented
11 months ago So I am posting a follow up to my issue, that I managed to resolve. I hope that it can help someone.
Firstly, I took a step back and looked at the entire flow properly. I forgot that we have a third party cloud WAF configured on the site (company decided to use Imperva a few years back). I decided to remove this from the equation, and test the app directly from the Azure domain url (mysite.azurewebsites.net).
I connected to the VPN, and was unable to reproduce the connection issue while using the Azure url directly. I switched back to the custom domain which routes via the WAF, and the issue returned!
At this point I decided that something was wrong with the WAF.
Then I ran some tests using https://www.ssllabs.com/ssltest/ to compare the SSL certificates for the Azure url (mysite.azurewebsites.net) vs the custom domain that we were using to route via the WAF (mysite.company.com).
I compared the results, and could see that the Azure url only supported TLS 1.2. The custom domain was supporting up to TLS 1.3.
I contacted Imperva support and asked how to configure my site to only use TLS 1.2. They advised that this is a setting that they have to manage on their end. I asked them to change it (gave them the list of TLS 1.2 ciphers that are supported via Azure only).
Once they made the change, I retested my site using the custom domain, and the connection issue while uploading files seems to have disappeared! I usually couldn't make it past 3-5 uploads, now I have uploaded almost 50 documents without any connection issues. I retested over a few days and it seems to be holding up.
TLDR version: Third party WAF supporting TLS 1.3 by default, asked WAF provider to downgrade to 1.2 and now its happy days. I understand that Microsoft might move Azure web apps to TLS 1.3 next year, might need to adjust again when that happens.
whew 😅
akshaybheda
commented
8 months ago Any idea when this would be resolved?
Describe the bug
I'm receiving what appears to be random exceptions on my web app. It's running ASP.NET Core 2.2.108 on Azure App Service (Windows). I've only seen it happening for a single endpoint which is a POST request with a file upload. The files are restricted to 5MB.
I'm struggling to reproduce the issue but was hoping someone might be able to make more sense of the stack trace than I can and point me in the right direction.
The outer type and message reported by App Insights is
Microsoft.AspNetCore.Connections.ConnectionResetExceptionandThe client has disconnected. Does this actually mean that the client device has lost it's internet connection (could be a mobile device)?The inner type and message are
System.Runtime.InteropServices.COMExceptionandAn operation was attempted on a nonexistent network connection. (Exception from HRESULT: 0x800704CD)My searching has led me to this issue but not sure if it's related in any way, https://github.com/aspnet/AspNetCore/issues/6415 the only place I can find the message
The client has disconnectedin the repo is here : https://github.com/aspnet/AspNetCore/blob/c60d1e1a14691a624f46b350f6561dc752e3964c/src/Servers/IIS/IIS/src/Core/IO/AsyncIOOperation.csHappy to provide more information if it is a genuine bug rather than something I'm doing wrong, just let me know.
Stack trace from App Insights is below: