Hi there,
this time I’d like to describe a pretty odd issue encountered a while ago.
We have a following scenario: We have an ASP.NET 4 web application, configured in IIS 7 only for basic authentication. The application uses quite a lot AJAX update panels and other javascripts. The problem that started occuring was the infamous Sys.WebForms.PageRequestManagerParserErrorException:
—————————
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 ScriptResource.axd ….
It happened only using IE (v.7,8,9), but since IE has always been a bit „different”, that was not the funniest fact about the problem. What was in fact strange, was that it happened only on some machines – I’ll come back to that later in this post.
However, all the hints pointing how to avoid that error failed. In fact, the application did not have any calls to Response.Write, Server.Transfer, neither http modules nor response filters. Trace was also disabled.
Not the first time, Fiddler came to rescue. I was able to notice that for each needed request for an aspx page, actually two requests were made. The first one was giving a HTTP status code 401 (access denied), then the second one was successful (HTTP 200). Analyzing the request headers the only difference between them was the authorization method. The request which gave 401 response had:
Authorization: NTLM DFGHJKLDRFGHNXAAAAA==
The second one had :
Authorization: Basic ZXVyasdasdasdasdasdasd=
Since the update panel and other asynchronous requests were getting a 401 response, the application was giving the error mentioned above.
Now, the question was, why would the NTLM authorization be enabled, if I had set explicitly in IIS the windows authentication method to be disabled? As mentioned earlier, only basic authentication was enabled. Since this app was also a sub-application of another one (which had windows authentication enabled), first thought was an inheritance problem of IIS settings. But the app having problems was overriding the parent setting (win auth disabled), so from that point of view it was OK.
As mentioned already earlier, the issue was occuring on some machines only. And there was the rub. The machines were the corporate ones of our company, and the website was added as an intranet site in Internet options. Additionally, the automatic logon for intranet zone was enabled:
This setting is forcing Internet Explorer first to try to authorize the user logged onto the machine in the domain. That failed, since NTLM/Windows auth was disabled in IIS. First then the 'correct’ basic authentication request was made.
As a solution you may either remove the application from intranet sites (if your/corporate policy allows it), or you may enable Windows authentication in the application instead of the basic one.
Hope it helps,
Łukasz