We have a site running on MOSS 2007 which makes calls to custom web service asmx methods on the same domain from the client.
On the live site requests are getting redirected to the following url:
http://[domain]/_layouts/error.aspx?ErrorText=Request format is unrecognized for URL unexpectedly ending in %27%2FIsSuspectWaterLevel%27.
We've added the following to the sites web.config without any joy:
<system.web>
<webServices>
<protocols>
<add name="HttpSoap" />
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
...
</system.web>
Interestingly enough we don't have this issue on the test server which is supposed to be pretty identical to the live server.
Any ideas to what other variable might be at play here?
Thanks in advance for any ideas,
Gavin
Update:
While a call to
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx/IsSuspectWaterLevel
fails, I can still access
http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel
though it fails when I invoke the method in the same way.
I wonder if this helps shed more light on the issue?
Another Update:
I've just observed the same error on the dev server. Removing the apps dll from GAC and then re-copying it in solved the issue. The live server tested fine with initial deployment so perhaps there's an issue with Sharepoint loosing some reference over time? Clutching at straws as very confusing behaviour!
Yet Another Update:
It seems everytime I touch (open and save) the web.config file in 12 Hives the problem is fixed again for a period, but after a while the problem comes back. I wonder if it's anything to do with the app pool being recycled?
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\ISAPI\web.config
An inelegant workaround to this issue that works for us: We've swapped out the web service asmx end point for a web handler ashx endpoint. This doesn't suffer the same issue for some reason.
I'm guessing from this that there's some issue creeping in after a period of time which is causing urls to resolve incorrectly. I suspect that the / after the .asmx in the url is the curprit. The ashx endpoint implemented is working purely on url parameters and posted data.
Obviously this work around won't always be an option for others who might experience the same issue as we're loosing a lot of the rich web service functionality that's pre-baked in to an asmx endpoint.
Unfortunately I won't be able to test any other solutions that people might put forward from now on as we've moved away from the web service asmx approach. Sorry.
Related
CF9
Exchange server 2007 (hosted)
I am trying to add a calendar event for a user on our hosted exchange server. I'm getting the error ;
Unable to connect to the Exchange server using HTTP/HTTPS protocol.
HTTP response code : 400
The code is;
<cfexchangeCalendar action="Create"
username="EXCH016\ron_domain"
password="password"
mailboxname="ron"
server="https://owa016.msoutlookonline.net/owa"
Protocol="https"
formbasedauthentication=true
formbasedauthenticationURL="https://owa016.msoutlookonline.net/owa/auth/owaauth.dll"
Event="#sEvent#"
result="theUID">
#theUID#<br>
I know I can contact the server using the following;
<cfhttp URL='https://owa016.msoutlookonline.net/owa' result='res' >
<cfdump var="#res#">
<cfoutput>#res.filecontent#</cfoutput>
I get the form that requests email address and password.
I've been working on this problem for some time now. I can go to the owa page via browser and log in. At this point I'm at a loss on how to debug the problem.
I have had the same type of problem in the past, when one of my customers went from Privately Hosted and Run vs Hosted Solutions.
Although, I never used the formbasedauthentication method when authenticating, maybe this bypasses some of my issues.
The big thing we had issues with is that most Providers don't all WebDav access on their servers.
Since you are getting a 400, bad request, this is what I would look for first.
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=cfexchange_3.html talks about what CF needs to connect to Exchange, maybe see if the support staff can confirm the setup.
Since you are using HTTPS, have you added the Cert into the JRE cert Store?
Sorry this probably isn't much help, but I hope it helps.
I am trying to program a VisualWebPart using Visual Studio 2010 which has to do a simple thing: invoke a web service (hosted in a remote server, NOT locally). When I execute within the Sharepoint site (version 2010, which I have published in my IIS) I get this error:
"The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'."
Pardon my ignorance, but the only difference here is the case of the Ntlm authentication scheme! I have been all over the web and found many related problems, but none of the solutions worked. Almost ALL solutions i found involve modifications in the webservice security configuration, this is not an option for me.
Looking for a solution, I created a sample windows form and invoked the web service from it: no problems whatsoever.
In order to be able to invoke the webservice correctly this is the necessary security configuration:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" proxyCredentialType="Ntlm" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
I believe the problem is that I haven´t been able to properly set this security property to the web.config of my Sharepoint site, since I tried to put it in the security tag that appears in the web.config but still get the same error.
Any further information needed please ask, I am REALLY desperate, for days I have been with the SAME error.
In the end I was given permissions in their server: more precisely in the database which was the one that wouldn't let me create the web part in the server. Once this was done, the call to the webservice worked just fine, because they have the web.config correctly configured.
I've a web service, which is basically a #Stateless EJB annotated with #WebService, and other JAX-WS related annotations. I can deploy this bean on my machine's glassfish instance, and see its WSDL through Glassfish's administrative GUI. I can also call its methods without any problems, from a SE client.
When I deploy this web service to a server instance in any other machine, I can no longer browse its WSDL through glassfish, and the client fails to connect to the server. The message displayed is:
Invalid WSDL request: http://ip:port/context/serviceEndpoint?wsdl
The HTTP error returned by Glassfish on such request is 405 (method not allowed).
I browsed around, and couldn't get anything directly related to glassfish v3. There are issues open on Glassfish's bugzilla for version 2, meaning they're old and have been labelled as CLOSED/FIXED already.
Anyone ran into this before? Any help or any clues about what could be happening here?
Thanks in advance!
For the sake of those who might come across this problem one day: I had OpenSSO on the target server. And by many obvious reasons, it was a classpath clashing problem that prevented the WSDL to be generated by glassfish.
Once OpenSSO has been removed of the equation, everything worked as it was supposed too. So, even if you're not an OpenSSO user, check your classpath for multiple Metro instances, or any other JAX related library that might be conflicting with glassfish's own on your domain.
I'm writing a compact framework 3.5 application for a windows mobile device. In this application I'm consuming a web service in order to sync with our database. However, whenever I try to make a call to the web service from the device or the emulator, I get the following error: Invalid URI: Hostname could not be parsed. I'm connected to the network via R-NDIS. The service is running on my development machine right now, and I'm actually able to browse to the asmx page through pocket IE. What am I missing?
Thanks!
This might be a proxy problem. The following worked for me.
var service = new WebService.Service();
service.Proxy = GlobalProxySelection.GetEmptyWebProxy();
You might not be picking up the proxy server IE is using, or pocket IE might be displaying a cached version of the ASMX page (and thus not really able to access it either). Probably neither one of these is your problem, however.
Update: try putting this in your application's config file:
<configuration>
<system.net>
<defaultProxy>
<proxy autoDetect="true" />
</defaultProxy>
</system.net>
</configuration>
We have a hybrid WCF and ASMX web service currently being used on a decent sized project. Now, most of time everything works perfectly fine, however on rare occasions and seemingly randomly, the web service begins to block calls which returns a 401 Unauthorized error back to the page in question. It seems to be the ASMX service calls that are causing this, but given that's it doesn't occur often and isn't reproducible I can't say this for certain.
The error goes away after an IIS reset, and at least on one occasion it eventually just went away on it's own. We use Windows Authentication as the credential type with anonymous access disabled.
Anyone have any ideas about why this might be occuring?
The solution we finally figured out was a small registry edit to disable the loopback check that causes the login issues with IIS. We had actually had this registry edit floating around but had forgotten about it over time.
The key is located at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Add a DisableLoopbackCheck DWORD with a value of 1 and that seems to take care of the problem
MS Support link: http://support.microsoft.com/kb/896861