HttpContext的抛出HttpException [英] HttpContext throws HttpException

查看:2407
本文介绍了HttpContext的抛出HttpException的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我写了一个自定义HTTP处理程序。我已经写它实现了IHttpHandler的类做到了这一点。

I have written a custom http handler. I have done this by writing a class which implements the IHttphandler.

在那个班我有code这个样子,

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

或者这样,

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()

这发生在生产,如果我回头看过去的几天错误已经发生了23次,共上述code被称为497次。

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.

我怀疑这种故障涉及到用户点击来启动上述code不止一次(这将给予他们多下载对话框),那么他们取消其中一些链接。话虽如此,如果它是类似的东西我本来期望的连接正常关闭两端。

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.

我怎么能证明这个错误的确切原因是什么?我试图让.NET跟踪这样的<一个href="http://stackoverflow.com/questions/6104103/why-dont-trace-listeners-log-custom-handler-traffic">Why不跟踪监听器记录的自定义处理程序的流量?的,但不能让它的工作。

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.

我发现的是,虽然我已经启用IIS跟踪登录失败的请求。再次发生故障,并没有在该日志。

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);
}

但是,这并没有什么差别。虽然我猜的原因是,客户端断开连接时下载正在发生,而不是调用flush之前。

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.

推荐答案

取出两个同花顺()关闭()通话。你真的不需要他们。一旦你的处理程序完成后,它会退出,而ASP.NET将处理关闭请求。

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.

此外,同花顺()应该当你流媒体内容给客户(以块为单位将部分响应流)使用。你并不需要使用它与的TransmitFile()

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的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆