当我在按钮的单击事件上写入 Response.write() 时出现错误

发布于 2024-08-26 19:57:13 字数 229 浏览 5 评论 0原文

Sys.Webforms.PageRequestManagerParserErrorException：收到消息无法解析来自服务器的信息。导致此错误的常见原因是当通过调用 Response.Write() 修改响应时，响应过滤器、HttpModules 或服务器跟踪已启用。详细信息：解析错误靠近 '

您好，我在更新面板中保留了按钮，但收到此错误

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

葬﹪忆之殇 2024-09-02 19:57:13

您不应在按钮的事件处理程序中使用 Response.Write。实际上，您根本不应该使用 Response.Write() ，除非您手动处理所有响应生成（然后您也可以使用 ashx 而不是 aspx）。

一种解决方法是在要显示文本的页面上放置一个文字控件，并在按钮单击事件中设置文字的值。

回复收藏 0 原文

靑春怀旧 2024-09-02 19:57:13

updatePanel 是 ajax 的自动方式，不能与 Response.Write() 一起使用，因为它需要在内存上渲染要发送的内容，而不是从页面传递。 Respose.Write()直接将输出发送到客户端，就像直接输出到客户端页面一样，但没有这个页面。因此 updatePanel 上的 Respose.Write() 会抛出异常。

将 Respose.Write() 替换为可能的文字，并将您想要显示的输出放入文字中。

回复收藏 0 原文

私野 2024-09-02 19:57:13

更普遍的原因是，某些防火墙/浏览器插件可以剥离 AJAX 相关的 HTTP 标头值 X-MicrosoftAJAX，从而破坏正常的页面渲染周期。

详细说明请参阅 Telerik 博客 Telerik 网站上的博客文章但似乎由于公司重组，他们失去了博客服务（希望是暂时的）。因此引用 Bing 缓存：

http://cc.bingj.com/cache.aspx?q=http%3a%2f %2fblogs.telerik.com%2fhristodeshev%2fposts%2f07-06-24%2ffirewalls_writing_asp_net_ajax.aspx&d=4534636468308322&mkt=en-GB&setlang=en-US&w=8ZCg4pTc8CwOHTBDOYwjhsvWm FHYT0tM

防火墙破坏了 ASP.NET AJAX！这个很严重，可能会咬你
任何时间。
昨天肖恩在我们的论坛中发布了这个问题：他和他的用户
在请求基于 ASP.NET AJAX 的站点时遇到奇怪的错误，
是的，这也意味着基于 RadControls“Prometheus”的。
UpdatePanel 控件发起的部分渲染请求失败
带有神秘的消息：
============== Sys.WebForms.PageRequestManagerParserErrorException: 无法解析从服务器接收的消息。常见原因
这个错误是当响应被调用修改时
Response.Write()、响应过滤器、HttpModules 或服务器跟踪是
已启用。详细信息： ' 附近解析错误
当然，所有这些都没有任何 Response.Write() 的痕迹，
HttpModule、响应过滤器或他的代码中的服务器端跟踪。这
恐怖，恐怖……
有幸成为一个已经实施了
类似于 ASP.NET AJAX 的框架，我注意到有些东西正在制作
ASP.NET AJAX 渲染整个页面并将其返回给浏览器
即使服务器代码应该处理部分
渲染请求。注意我的强调（粗体部分是开头
一个普通的 HTML 文档）：
============== Sys.WebForms.PageRequestManagerParserErrorException: 无法解析从服务器接收的消息。常见原因
这个错误是当响应被调用修改时
Response.Write()、响应过滤器、HttpModules 或服务器跟踪
已启用。详细信息：在 *****' 附近解析错误
我相信 Watchguard 的人应该获得 X-MicrosoftAjax 标头
很快就进入他们已知的标题列表。直到他们这样做为止，请
禁用该设置。我认为它们不是唯一的防火墙解决方案
可能有此问题的提供商。你在后面吗
标头剥离防火墙？请在下面发表评论！我不是说
仅限企业解决方案——个人防火墙也可以做到这一点。
我们的清单越大，让某人免受伤害的机会就越大
棘手的问题。
另一方面，防火墙是否有充分的理由剥夺您的
HTTP 请求头？我能想到的就是古老的系统管理员
“禁用用户不需要的所有内容，然后继续
继续并禁用更多。”

More generic reason is that some firewalls/browser plugins can strip AJAX related HTTP header value X-MicrosoftAJAX and thus normal page rendering cycle is broken.

Detailed explanation was available in Telerik blog Blog post on Telerik site but seems due to company reorganization they lost blog service (hope that temporarily). So quote from Bing cache:

http://cc.bingj.com/cache.aspx?q=http%3a%2f%2fblogs.telerik.com%2fhristodeshev%2fposts%2f07-06-24%2ffirewalls_breaking_asp_net_ajax.aspx&d=4534636468308322&mkt=en-GB&setlang=en-US&w=8ZCg4pTc8CwOHTBDOYwjhsvWmFHYT0tM

Firewalls breaking ASP.NET AJAX! This one is serious and may bite you
any time.
Yesterday Shaun posted this problem in our forums: he and his users
were experiencing odd errors when requesting ASP.NET AJAX-based sites,
and yes, that means RadControls "Prometheus" based ones as well.
Partial rendering requests initiated by UpdatePanel controls failed
with the cryptic message:
============== Sys.WebForms.PageRequestManagerParserErrorExeption: The message received from the server could not be parsed. Common causes
for this error are when the response is modified by calls to
Response.Write(), response filters, HttpModules, or server trace is
enabled. Details: Error parsing near '
Of course all that comes without any trace of Response.Write(),
HttpModule, response filter or server-side tracing in his code. The
horror, the horror...
Having the luxury of being a part of a team that has implemented a
framework similar to ASP.NET AJAX, I noticed that something was making
ASP.NET AJAX render the entire page and return it back to the browser
even when the server code was supposed to be handling a partial
rendering request. Note my emphasis (the bold part is the beginning of
a normal HTML document):
============== Sys.WebForms.PageRequestManagerParserErrorExeption: The message received from the server could not be parsed. Common causes
for this error are when the response is modified by calls to
Response.Write(), response filters, HttpModules, or server trace is
enabled. Details: Error parsing near *****'
I believe the Watchguard guys should get the X-MicrosoftAjax header
into their known headers list pretty quick. Until they do, please
disable that setting. I think they are not the only firewall solutions
provider that may have this problem. Are you behind a
header-stripping firewall? Please post a comment below! I don't mean
corporate solutions only -- personal firewalls can do that as well.
The bigger list we have, the greater chance of sparing somebody a
tough problem.
On the other hand, is there a good reason for a firewall to strip your
HTTP request headers? All I can think of is the age-old sysadmin
principle of "Disable all that your users don't need, and then go
ahead and disable some more."