Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it

Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to
avoid it

If you've used the Microsoft ASP.NET AJAX
UpdatePanel
control, there's a good chance you've hit the
"Sys.WebForms.PageRequestManagerParserErrorException" error.

What's a PageRequestManagerParserErrorException?

The UpdatePanel control uses asynchronous postbacks to control which parts of
the page get rendered. It does this using a whole bunch of JavaScript on the
client and a whole bunch of C# on the server. Asynchronous postbacks are exactly
the same as regular postbacks except for one important thing: the rendering.
Asynchronous postbacks go through the same life cycles events as regular pages
(this is a question I get asked often). Only at the render phase do things get
different. We capture the rendering of only the UpdatePanels that we care about
and send it down to the client using a special format. In addition, we send out
some other pieces of information, such as the page title, hidden form values,
the form action URL, and lists of scripts.

As I mentioned, this is rendered out using a special format that the
JavaScript on the client can understand. If you mess with the format by
rendering things outside of the render phase of the page, the format will be
messed up. Perhaps the most common way to do this is to call Response.Write()
during Page's Load event, which is something that page developers often do for
debugging purposes.

The client ends up receiving a blob of data that it can't parse, so it gives
up and shows you a PageRequestManagerParserErrorException. Here's an example of
what the message contains:

---------------------------
Microsoft
Internet
Explorer
---------------------------
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 'Hello,
World!106|upd'.
---------------------------
OK
---------------------------

If you ask me, this error message is not all that bad. After all, I'm the one
that made it :) The details indicate what was being parsed when it decided to
give up. You can see the part of the text from my Response.Write(), and
immediately after that is part of the special format I keep mentioning.

Why do I keeping getting a
PageRequestManagerParserErrorException?

Well, chances are you're doing one of the things mentioned in the error
message. Here are the most common reasons and why they don't work:

Calls to Response.Write():
By calling Response.Write() directly you are
bypassing the normal rendering mechanism of ASP.NET controls. The bits you write
are going straight out to the client without further processing (well,
mostly...). This means that UpdatePanel can't encode the data in its special
format.

Response filters:
Similar to Response.Write(), response filters can
change the rendering in such a way that the UpdatePanel won't know.

HttpModules:
Again, the same deal as Response.Write() and response
filters.

Server trace is enabled:
If I were going to implement trace again, I'd
do it differently. Trace is effectively written out using Response.Write(), and
as such messes up the special format that we use for UpdatePanel.

Calls to Server.Transfer():
Unfortunately, there's no way to detect that
Server.Transfer() was called. This means that UpdatePanel can't do anything
intelligent when someone calls Server.Transfer(). The response sent back to the
client is the HTML markup from the page to which you transferred. Since its HTML
and not the special format, it can't be parsed, and you get the
error.

How do I avoid getting a
PageRequestManagerParserErrorException?

To start with, don't do anything from the preceding list! Here's a matching
list of how to avoid a given error (when possible):

Calls to Response.Write():
Place an <asp:Label> or similar control
on your page and set its Text property. The added benefit is that your pages
will be valid HTML. When using Response.Write() you typically end up with pages
that contain invalid markup.

Response filters:
The fix might just be to not use the filter. They're
not used very often anyway. If possible, filter things at the control level and
not at the response level.

HttpModules:
Same as response filters.

Server trace is enabled:
Use some other form of tracing, such as writing
to a log file, the Windows event log, or a custom mechanism.

Calls to Server.Transfer():
I'm not really sure why people use
Server.Transfer() at all. Perhaps it's a legacy thing from Classic ASP. I'd
suggest using Response.Redirect() with query string parameters or cross-page
posting.

Another way to avoid the parse error is to do a regular postback instead of
an asynchronous postback. For example, if you have a button that absolutely must
do a Server.Transfer(), make it do regular postbacks. There are a number of ways
of doing this:

The easiest is to simply place the button outside of any UpdatePanels.
Unfortunately the layout of your page might not allow for this.

Add a PostBackTrigger to your UpdatePanel that points at the button. This
works great if the button is declared statically through markup on the
page.

Call ScriptManager.RegisterPostBackControl() and pass in the button in
question. This is the best solution for controls that are added dynamically,
such as those inside a repeating template.

Summary

I hope I've answered a lot of questions here and not angered too many of you.
We're looking at ways to improve some of these situations in the next version of
ASP.NET, but of course there are no guarantees. If you avoid changing the
response stream, you're good to go. If you absolutely must change the response
stream, simply don't do asynchronous postbacks.