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 '<!DOCTYPE html P''.
==============
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 *****'<!DOCTYPE html P''******.
==============
I dug a bit deeper using the .NET documentation browser (Reflector), trying to find out how ASP.NET AJAX "knows" when to let the page render itself and when to intercept the normal rendering and send the updated UpdatePanels' contents only. The answer is simple: the client code sets a special HTTP header that gets read by the server. The header is "X-MicrosoftAjax" and its value is "Delta=true". Then it dawned on me that some firewall "solution" may be stripping or tampering with that header. Shaun confirmed this: his company is using a Watchguard router that has this setting of "Remove Unknown Headers". Disabling that, made the problem disappear.
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."