Internal Server Error - Webservice

I have a page that calls a webservice through Ajax ServiceManager. When I run the appication on my workstation everything is fine. When I move it to the server and access the page from the server it works fine. When I try to access it from my workstation I get "Internal Server Error". I have read the documentation on using Webservices in Ajax and I think I am doing everything correctly.. Any ideas?

Thanks,

Don

I think you have an authentication problem here. Maybethis thread will help you. Do you use forms authentication ?

Laurent

He Don.Net,

are you requesting your webservice from javascript? Can you past your code from your webservice here and the way you make a request to your webservice! thanks

Regards,

Found solution. Added the following to web.config.

<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>

Everything works fine now.

Thanks

I am having a similar problem and I'm getting frustrated. I have a (really) simple web service (running in SharePoint):

[WebMethod]
[System.Web.Script.Services.ScriptMethod]
publicdouble UpdateValue(double newValue)
{
// return 0;
thrownewException("There may have been an error. Or there may not have been. It's really hard to say.");
}

which I'm calling from AJAX on the client browser. If I uncomment the return 0 everything works fine. If I throw the exception above or any other exception all I recieve on the client is an HTTP 500 error. I have included the web.config changes listed above (and others I've found googling) and I still get the generic error. If I call this service from a Windows Form app I receive the correct exception (in the inner exception). How can I view on the client the exception I've thrown on the server? Any help would be greatly appreciated.

Thanks.

From my point of view is youre Problem by Design. Exceptions they are thrown in a WebService store there InnerExceptionMessage in a SOAP Message, If you're call the WebService with a Windows-App, a WebReference is created and the communication is via SOAP. JavaScript invoke the WebService via http, and you can't access the SOAP-Message with the Exception inside.

Hope that helps

Thanks for you're response. After further investigation I'm even more confused. And this may be a question for a SharePoint group instead. When my web service is in the _vti_bin virtual directory my AJAX request receives a generic 500 server error whenever I throw an exception. But if I move my web service to a new virtual directory, /services, then AJAX's get_StackTrace & get_Message are both populated correctly. I thought I could fix this through web.config changes but it may be something inherent to the way SharePoint virtualizes paths.

Im not sure that its a sharepoint specific problem. I believe its a .Net web services from js problem. And more specifically It appears to be in the authentication realm..

I say this because I am encountering the exact same 500 Internal Server error message from my javascript when I hit my CRM 3.0 web service from anywhere but the hosted server. I have tried the links above (adding <location path="myserviceweblocation"> around <system.web> as well as the <protocols>) and I am still encountering the problem. My intuition has led me to believe it was an authentication problem the entire time but its very hard to find a solution for this extremely generic error. It seems this is the most helpful group on the web. So even though this is an ajax forum would you guys mind giving me some help? Here is my web.config for my webservices virtual folder:

=======================================================================

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<location path="DupService">

<system.web>

<!-- DYNAMIC DEBUG COMPILATION

Set compilation debug="true" to enable ASPX debugging. Otherwise, setting this value to

false will improve runtime performance of this application.

Set compilation debug="true" to insert debugging symbols (.pdb information)

into the compiled page. Because this creates a larger file that executes

more slowly, you should set this value to true only when debugging and to

false at all other times. For more information, refer to the documentation about

debugging ASP.NET files.

-->

<compilation

defaultLanguage="c#"

debug="true"

/>

<!-- CUSTOM ERROR MESSAGES

Set customErrors mode="On" or "RemoteOnly" to enable custom error messages, "Off" to disable.

Add <error> tags for each of the errors you want to handle.

"On" Always display custom (friendly) messages.

"Off" Always display detailed ASP.NET error information.

"RemoteOnly" Display custom (friendly) messages only to users not running

on the local Web server. This setting is recommended for security purposes, so

that you do not display application detail information to remote clients.

-->

<customErrors

mode="Off"

/>

<!-- AUTHENTICATION

This section sets the authentication policies of the application. Possible modes are "Windows",

"Forms", "Passport" and "None"

"None" No authentication is performed.

"Windows" IIS performs authentication (Basic, Digest, or Integrated Windows) according to

its settings for the application. Anonymous access must be disabled in IIS.

"Forms" You provide a custom form (Web page) for users to enter their credentials, and then

you authenticate them in your application. A user credential token is stored in a cookie.

"Passport" Authentication is performed via a centralized authentication service provided

by Microsoft that offers a single logon and core profile services for member sites.

-->

<authentication mode="None" />

<!-- AUTHORIZATION

This section sets the authorization policies of the application. You can allow or deny access

to application resources by user or role. Wildcards: "*" mean everyone, "?" means anonymous

(unauthenticated) users.

-->

<authorization>

<allow users="*" /> <!-- Allow all users -->

<!-- <allow users="[comma separated list of users]"

roles="[comma separated list of roles]"/>

<deny users="[comma separated list of users]"

roles="[comma separated list of roles]"/>

-->

</authorization>

<!-- APPLICATION-LEVEL TRACE LOGGING

Application-level tracing enables trace log output for every page within an application.

Set trace enabled="true" to enable application trace logging. If pageOutput="true", the

trace information will be displayed at the bottom of each page. Otherwise, you can view the

application trace log by browsing the "trace.axd" page from your web application

root.

-->

<trace

enabled="true"

requestLimit="10"

pageOutput="true"

traceMode="SortByTime"

localOnly="true"

/>

<!-- SESSION STATE SETTINGS

By default ASP.NET uses cookies to identify which requests belong to a particular session.

If cookies are not available, a session can be tracked by adding a session identifier to the URL.

To disable cookies, set sessionState cookieless="true".

-->

<!--<sessionState

mode="InProc"

stateConnectionString="tcpip=127.0.0.1:42424"

sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"

cookieless="false"

timeout="20"

/>-->

<!-- GLOBALIZATION

This section sets the globalization settings of the application.

-->

<globalization

requestEncoding="utf-8"

responseEncoding="utf-8"

/>

<webServices>

<protocols>

<add name="HttpGet"/>

<add name="HttpPost"/>

</protocols>

<webservices>

</system.web>

</location>

</configuration>

==================================================================

Mostly generic stuff. As a note I have tried the most generic web service (hello world) and very simple XmlHttp javascript objects.

Found a solution. I must admit Im a bit curious as to why it didnt show up anywhere else.

Web service which was only a test application was running on the C:\testService folder and linked via IIS. When it was moved to the Inetpub\wwwroot directory AND added:

<system.web>

<webServices>

<protocols>

<add name="HttpGet"/>

<add name="HttpPost"/>

</protocols>

<webServices>

</system.web>

Then it began to work on all systems.