发送 HTTP 标头后,服务器无法附加标头?
我在 IIS 7 上运行的 Asp.Net 网站的事件日志中收到以下警告。
Exception information:
Exception type: HttpException
Exception message: Server cannot append header after HTTP headers have been sent.
at System.Web.Hosting.ISAPIWorkerRequest.SendUnknownResponseHeader(String name, String value)
at System.Web.HttpResponse.WriteHeaders()
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext context, Exception e)
我尝试调试该网站,但它没有在调试器中显示。出现此问题的网页包含以下内容。
- 它是一个带有母版页的内容页。
- 它在 UpdatePanel 内有一个由计时器触发的网格。
- 在指定的时间刷新网格数据。
每次发生这种情况时,我们都会在事件日志中看到新的警告。解决这个问题的最佳方法是什么?
I am getting the following warnings on the Event Log for a Asp.Net WebSite running on IIS 7.
Exception information:
Exception type: HttpException
Exception message: Server cannot append header after HTTP headers have been sent.
at System.Web.Hosting.ISAPIWorkerRequest.SendUnknownResponseHeader(String name, String value)
at System.Web.HttpResponse.WriteHeaders()
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext context, Exception e)
I tried to debug the WebSite but it just does not show in debugger. The web page which has got this issue contains the following.
- Its a content page with a Master page.
- It has a grid inside an UpdatePanel which is Triggered by a Timer.
- On the specified time grid data is refreshed.
Everytime this happens we see a new warning in the EventLog. What is the best way to go about this issue?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
你有一个行为不当的控件。您可以在将任何内容写入响应流之前的任何时刻添加标头,在该点之后添加标头将抛出异常。
异常被抛出得很深,因此您必须尝试“调试”>“异常”>“公共语言运行时异常”并检查“抛出”。现在可以中断异常并检查内部异常或跟踪调用堆栈并找出谁是坏人。
You have a control that is misbehaving. You may add headers at any point before any content is written to the response stream, after that point adding a header will throw.
The exception is being thrown deep so you will have to try Debug>Exceptions>Common Language Runtime Exeptions and check 'thrown'. It may now be possible to break on the exeption and examine the inner exception or trace the call stack and find out who is being bad.