Response.Redirect("~/MainScreen.aspx") ‘成功
Server.Transfer("~/MainScreen.aspx") ‘失败
Sys.WebForms.PageRequestManagerParserErrorException:The message received from the server
count 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 '|<html>
<head>
==================
此前，我定义了web.config的customError 段，使系统中一旦发生异常，就转到自定义的错误页面， 但是这样做有一个很严重的问题， 就是无法看到异常的信息， 最近我越来越觉得无法忍受这一点， 于是换了一种做法， 在global.asax中， 自定义Application_Error 事件，在这里可以得到异常的信息， 然后把它传递给错误页面， 最终用Server.Transfer 方法转到错误页面.
之所以用Server.Transfer 不仅是出于效率的考虑， 而且因为它不显示错误页面的url，显示的仍然是抛出异常的页面的url， 这一点很好， 而且在开发时可以直接刷新来更新原页面. 但是不幸的是它并不总是有效， 在某些情况下， 抛出异常的页面并没有定向到错误页面， 而是显示一个脚本错误:
Sys.WebForms.PageRequestManagerParserErrorException: 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 '
<!DOCTYPE html P'.
这个错误超出了我的理解范围，于是我求助于Google，发现了这样一篇文章:No, you cannot call Server.Transfer on an ASP.NET AJAX enabled page，这一来就明白了，没有出错的页面是没有使用UpdatePanel的，而凡是使用了UpdatePanel的页面都会报这个错。错误的原因：部分回发总是由客户端的PageRequestManager 对象引起的，它等待服务器给出的答复，并动态刷新页面，但是使用了Server.Transfer以后，服务器会发回另一个页面的内容，这不是PageRequestManager 认为它应该看到的东西，所以就会产生Parse错误，进而当然Server.Transfer也就失效了。
解决的办法很简单，用Response.Redirect。
顺便说一句的是，如果像我一样在Application_Error中处理异常并转到一个固定的错误页面，则Application_Error事件中必须对错误页面做特殊的处理，因为一旦这个错误页面自己产生了异常，就会形成死循环，这个死循环会快速地向IIS日志中写入大量的垃圾数据，直至塞满硬盘而使整个服务器down掉。
======================
Server.Transfer in an UpdatePanel
by Arnold Matusz 6 10 2008While writing a short piece of code for my global exception handling post I figured out a nice fact. What I wanted to achieve is to have redirection to a custom error page which displays exception details. This can be easily done by using Response.Redirect() (to ex: ~/exception.aspx"), but this will completely lead to another page. This is not usefull if I'm interested in the actual URL where the exception has been thrown. (ex: ~/products.aspx?catid=4&pageid=7 ..."). By using Response.Redirect() you end up with "/exception.aspx" as the URL in the browser.
An obvious solution at first sight is ... we need to use Server.Transfer() which won't create a new Context (i.e.: the url in the browser will stay the same but we show the contents of a completely new page). And of course this is all fine ... until you need to use this functionality in an ASP.NET AJAX enabled website in an UpdatePanel.
By calling Server.Transfer() during an asynchronous postback the following alert will be displayed:
Sys.WebForms.PageRequestManagerParserErrorException: 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 '
<!DOCTYPE html P'.
The reason why you can't use a Server.Transfer() in an UpdatePanel is more and more obvious when you think about what AJAX is. We only request small pieces of markup which replace little portions of a page, the whole point of AJAX is to avoid downloading the whole page again. This means that when triggering an async postback, the PageRequestManager expects to receive some small portion of HTML, but because the Server.Transfer() call was made the actual response is the markup for a completely new/different page (which begins with the DOCTYPE definition, this is what you can see at the end of the exception message).
If you decide to use a Server.Transfer() in an UpdatePanel you can avoid this exception by setting your Trigger to a PostBackTrigger. (i.e. The control which fires the method where Server.Transfer() is called won't cause an async postback!).
http://blog.dreamlabsolutions.com/post/2008/10/06/Server-Transfer-in-an-UpdatePanel.aspx
http://yuanxunwen.blog.hexun.com/29306158_d.html
http://moosdau.blog.163.com/blog/static/437112820092274857393/