Login prompt when opening Office documents from a public SharePoint site

Hi there,

we have a following scenario:

  • a MOSS 2007 web application,
  • publicly accessible,
  • its URL added in Internet Explorer to the intranet sites,
  • checked in and published office documents within this site.

The problem occurring is that when one wants to open a MS Office document from the site using Internet Explorer, the Office application (Word, Excel..) is asking for username and password, although the document is publicly visible and not password-protected. Even if one clicks „Cancel” on the login prompt, the file is opened seamlessly.

After some research, I came across two possible solutions that can be applied in order to get rid of the unnecessary login prompt: either remove the URL from IE’s intranet sites list (which might not be desired because of other benefits of intranet sites), or make  following changes in the applications settings in IIS (7):

Go to the web site’s features, open the request filtering feature, and in the „HTTP Verbs” tab, add a deny rule for the verbs „OPTIONS” and „PROPFIND„. In my case, the use of checking in/out documents, opening them in read-only mode etc., was not necessary in this application, thus the verbs could be inhibited without the loss of other needed functionalities.

More information can be found in this KB article.

Hope this helps,

Sys.WebForms.PageRequestManagerParserErrorException in an intranet-zone web application (IE)

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:


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:

automatic logon only in intranet zone

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,

IE’s attachment handling on Tomcat via https


today something from a bit different discipline. Recently some users of one of java applications running in the company reported quite odd behavior. While they were trying to download any attachment / binary file generated by the application, they got the following error message as popup in Internet Explorer (versions 7 and 8):

„IE cannot download…………IE not able to open site..requested site is unavailable or cannot be found…”

After the message, the download was suspended and they couldn’t get the attachments. In all other browsers (FF, Opera, Chrome and Safari tested) the problem was not occuring. The application is running over https on Apache Tomcat 6.

First suspect was of course a bug in the application. After some research it turned out not to be the case. It seems to be a bug in Internet Explorer itself. Non-cache headers seem to prevent the browser from downloading attachments when working over a secure channel. Microsoft released a hotfix for it, but apparently only for the IE 6.

In order to workaround the issue, one can force Tomcat not to send the non-cache headers on response. The way to do that is to put the following valve in the Context.xml configuration file of the server (between <context> tags):

<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="false" />

After that (server restart required), it seems to work fine, with no side effects.

Hope this helps,

“Please wait while scripts are loaded…”

Hello again,

Some of Sharepoint developers might be familiar with this kind of message. It appears in the status bar of Internet Explorer when some action is executed. If the message disappears, fine, but what if it remains there and the desired behavior isn’t executed?

There are a couple of blog entries over the net that describe possible reasons for this issue. What actually causes this behavior are either errors in a masterpage (wrong or missing ID’s of elements that are later referenced), or defective javascript. Well, to be clearer, defective javascript from Internet Explorer’s point of view. And it may take w while to debug and find out at which point the javascript is failing.

I was getting this “Please wait while scripts are loaded” message on a web part page with one particular web part, which had some custom verbs defined. Web part verbs are kind of menu items for a web part, that allow to perform some actions on it. For each verb, one can define server-side and client side action to be performed when the verb / menu item is clicked. And this client side code of the verb was the crux of the matter.

The idea was simple: to open a window via javascript. For the window.open() method two arguments were used, the URL and the name of the new window. The client side code was generated dynamically and the window’s name was put up together, amongst others, from personalizable properties of the web part. Everything worked fine until the property used as part of window’s name contained a hyphen (-). Then, after clicking on web part menu, the message described above appeared, and nothing happened, new window hasn’t been opened.

I replaced the string with an underscore and the problem was solved. At this time I thought that maybe the names or ID’s in aren’t allowed to contain characters like hyphen. But no, according to W3C, hyphens are allowed since they’re not the first character of ID or name. Probably Internet Explorer tries to evaluate the expression, treating the hyphen as a minus sign. And reaches a deadlock at some point (please wait while scripts are loaded…)

Hope this helps,