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 PUBLI’.
So what’s happening here? The UpdatePanel mechanism works by requesting the whole aspx page from the server and then using black-boxed JavaScript code to grab the changes that the UpdatePanel area represents in order to update the browser accordingly. This requires that the UpdatePanel’s client side script gets exactly the page it was expecting. Any changes, such as using document.write or traces will upset this requirement and you get this error. Another way of upsetting this apple cart is if the server decides to totally change the page, i.e. the server issues a Server.Transfer. Server transfer is a very seductive technique because it doesn’t require bouncing any requests off the client, the server simply changes (transfers) from rendering page A to rendering page B. However, when we look back at the UpdatePanels requirements for having the same page then it quickly becomes obvious that it’s going to get upset again! So that’s it, I now know how to avoid upsetting the UpdatePanel, well so you’d think. In the particular case I was asked to look at the server was issuing a page redirect. At first thought you’d think, "aha, it must be the page the UpdatePanel expects", but no. The UpdatePanel is savvy enough to realise that a 303 redirect isn’t really meant for it, so it passes it to it’s container, i.e. normally the browser window. So although you can’t use the "page moved" technique to change the service end-point at least the server code can issue redirects without having to know if the client is a browser or an UpdatePanel. So why am I seeing the error still? Hmm, I’m still not sure. Something somewhere is consuming the 303 redirect and then correctly requesting the page B from the Server. Page B is then consumed by the UpdatePanel, therefore behaving like a Server.Transfer and hence I see the error. Unfortunately the page structure is complex, with a number of dynamically created controls and iframes so something in that goo is consuming the 303 before the UpdatePanel. So what’s a developer to do? Well handle the error that’s what 😉 Rather than write lots of nasty code to dynamically rewrite the UpdatePanel’s JavaScript you can use the following, Sys.WebForms.PageRequestManager endRequest Event
In my case I chose to examine the error condition, if there’s one the change the window.location and redirect the client to an error page. You can examine the args to see exactly what was returned to make more interesting decisions about how to process the error. Also you should mark the error has handled (=true) if you don’t want the UpdatePanel to carry on raising browser errors.
IT Bytes 