HttpContext throws HttpException(HttpContext 抛出 HttpException)
问题描述
I have written a custom http handler. I have done this by writing a class which implements the IHttphandler.
Inside that class I have code like this,
context.Response.Clear();
context.Response.ClearHeaders();
context.Response.AddHeader("Content-Disposition", "attachment;filename=" + attachmentFileName);
context.Response.AddHeader("Content-Length", new FileInfo(downloadFile).Length.ToString());
context.Response.ContentType = GetMimeType(attachmentFileName);
context.Response.TransmitFile(downloadFile);
context.Response.Flush();
context.Response.Close();
Occasionally I receive an error like this,
Exception HttpException The remote host closed the connection The error code is 0x800703E3
Or this,
Exception HttpException The remote host closed the connection The error code is 0x80070040
In both cases the stack trace is this,
at System.Web.Hosting.IIS7WorkerRequest.RaiseCommunicationError(Int32 result, Boolean throwOnDisconnect)
at System.Web.Hosting.IIS7WorkerRequest.ExplicitFlush()
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
This occurs in production, and if I look back over the last few days errors have occurred 23 times, and in total the above code has been called 497 times.
I suspect this failure relates to the user clicking the link to initiate the above code more than once (which will give them multiple download dialogs) then they cancel some of them. Having said that if it was something like that I would have expected the connection to close gracefully at both ends.
How can I prove the exact cause of this error? I have tried to enable .NET tracing like this Why don't trace listeners log custom handler traffic? but couldn't get it to work.
What I found though is that I have enabled IIS tracing to log failed requests. The failure occurred again, and NOTHING was in that log.
Any other tracing I can enable for instance?
The next thing I tried was this,
if (context.Response.IsClientConnected)
{
context.Response.Flush();
context.Response.Close();
}
else
{
LogMessage("Client has disconnected before flush was called", Severity.Information);
}
But that didn't make any difference. The reason though I guess is that the client disconnected while the download was taking place, not before flush was called.
Take out both the Flush()
and Close()
call. You really don't need them. Once your handler is done, it'll exit, and ASP.NET will handle closing the request.
Besides, Flush()
should be used when you're streaming content to the client (adding parts to the response stream in blocks). You don't need to use it with TransmitFile()
.
这篇关于HttpContext 抛出 HttpException的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:HttpContext 抛出 HttpException
基础教程推荐
- 为什么Flurl.Http DownloadFileAsync/Http客户端GetAsync需要 2022-09-30
- 有没有办法忽略 2GB 文件上传的 maxRequestLength 限制? 2022-01-01
- 如何在 IDE 中获取 Xamarin Studio C# 输出? 2022-01-01
- MS Visual Studio .NET 的替代品 2022-01-01
- 将 Office 安装到 Windows 容器 (servercore:ltsc2019) 失败,错误代码为 17002 2022-01-01
- SSE 浮点算术是否可重现? 2022-01-01
- 将 XML 转换为通用列表 2022-01-01
- c# Math.Sqrt 实现 2022-01-01
- rabbitmq 的 REST API 2022-01-01
- 如何激活MC67中的红灯 2022-01-01