Help: WebResource.axd Not Serving for Some Users

I've got a bizarre situation where a call to webresource.axd for some users is failing -- and only some users. Everything is installed on the server, and as far as I can tell it is all setup correctly -- and this is demonstrated by 95% or more of the users not having any problem. But these particular users have this problem getting webresource.axd regardless of the computer, network, or browser -- other members on my team can take the same user credentials and repeat the problem, while other good users continue to work on all the same computers. We are able to consistently reproduce the problem as we have identified a commonality between these user accounts -- the length of their login email is between 27 and 30 characters inclusively. Of course that login email is no where used to pull webresource.axd to my knowledge, but it is maybe somehow part of the session authentication cookie -- and maybe that's why things are failing. But I do not know of anything else to look at as far as configuration and authentication goes to troubleshoot -- we do not have this problem in our QA environment, nor do we have this problem for existing users (just newly registered users). We are using BEA's Plumtree ALUI 6.5 portal, so its a very complex and particular environment that I wouldn't expect others to have -- but maybe someone else has experienced something similar or has a thought.



  • Paul,

    What do you mean by "call to...for some users is failing"? Did you try make a direct request for the resource? What error does the server respond with?

    Try using Fiddler to see the requests and look at what is being sent and what is being returned for the axd requests when logged in as one of those users.


  • It looks like the problem lies entirely with the portal's gateway, as the webresource.axd is being sent from IIS even when the portal does not serve it up. It looks like we have a viable work-around by making our internal calls from our portal server to our .net portlet servers be https, matching our external client calls to our portal server, although that doesn't really make sense that it would matter.

  • I had the similiar problem too!!
    but i had resolved it ,i found the resolution from a site named microsfot technology and certification faqs .
    Maybe ,you could also find the answer too!!!
    Hope i can help you !

Comments have been disabled for this content.