![]() ![]() ![]() This was made even more insidious by the fact that the original code in. I've since fixed that (as you can see in the screen shot above), but it looked quite different before when I was trying to track down the bug. and the SendResponse() await warning was simply lost in the shuffle of a nearly 200 warnings. Because this code is ancient there are tons of, documentation and unused variable warnings etc. In my defense (ha!), I missed this because it's a legacy project that has been ported from a classic ASP.NET HttpHandler to an ASP.NET Core middleware component. So the tooling can help avoid this error and in most cases that's probably a pretty obvious catch. Now that I know where to look, I could see the warning at the scene of the crime: With a warning in that async call is called without awaiting the result. But Rick - don't you look at Warnings?Ĭhances are your Visual Studio, Rider and OmniSharp development environments/tools all should flag this call: SendResponse() // sometimes no workey Note that no error appears in the ASP.NET application if the latter occurs - it fails silently. This appears to be a timing issue - it works when the writing completes before ASP.NET shuts down the actual connection, or it fails if the entire response has not been written. In most cases the latter code actually works fine, and only occasionally would the code fail with the odd errors described above. NET Core 3.1 the intermittent errors kept cropping up.NET Core 3.1 and later is more strict with its async output generation as requests go through the IHttpFeatures pipeline rather than to direct Response output which seems to exacerbate the problem. NET Core 2.1 without issues even without the await in place, but in. I had this code running for some time on. This is perfectly valid C# code, although in this case not correct in terms of behavior.Īnd that right there is the culprit for the intermittent failures. (int) msResponseOutput.Length - (int) ContentPosition) Īnd the method should then be called like this: await SendResponse() // internally eventually does `await Response.WriteAsync(outputBytes)`īut because this is legacy code that was moved from an old HttpHandler I forgot to add the await in this call and left it as it originally was: SendResponse() // sometimes no workey eventually writes manipulated bytes into the output streamĪwait (msResponseOutput.ToArray(), pick up response data, add headers, re-route file transfers etc. The response writing method in question looks like this: public async Task SendResponse() It turns out that in this application I failed to call an output generation method with an await statement. Most of the times it works, sometimes it doesn't. even worse: it works most of the time - it only fails occasionally on the same pages, creating the exact same content. ![]() Apparently ASP.NET Core is cutting the connection before the final output is sent, even though it appears that all bytes have been received per Fiddler.Īnd. And yes, I logged the actual content size sent to the client and it matches the Content-Length header the client sees in Fiddler.Īs you can imagine, it took a while and a lot of false starts to find the culprit. Looking at the actual response output in Fiddler, it looks like the HTML output is all there and matches the content length generated on the server. This happens both with and without Fiddler attached. It comes up as a totally white page - not as an error, just blank. Which seems to suggest that the response was aborted ( X-ABORTED-WHEN). Per Eric Lawrence (the original author of Fiddler) I also checked the Session properties: Notice that the response code is a 200 response, but yet it shows with an error icon next to it. It refers to an intermittent failure of HTTP requests in a custom middleware component where I would get HTTP errors even though the actual response apparently was received properly. In this post I'll discuss a nasty bug I ran into with my code, and which I totally misdiagnosed at first. This post falls into the category of stupid developer mistakes that are difficult to track down.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |