views:

65

answers:

2

We've having trouble deploying a web service that works in our development environment, but not in production. Part of the problem is that our production servers are load-balanced, so to upgrade one of the servers, we have to take it out of the load-balance and try to test the sever in isolation, which is a challenge.

The computer I'm working on is called Web01 and the computer I'm using to test is called Ts01. On both machines, I've modified the hosts file to redirect mydomain.com to the approrpiate IP of the web site on Web01.

I'm testing two ways of accessing the web service on each machine:

  • A simple browser call to http://www.mydomain.com/services/myservice.asmx?WSDL.
  • A VB6 test app that calls the web service using the WSDL referenced above via SOAPClient.

Here are the results of the test:

                   Browser              VB6 App
    Ts01             OK                   OK
    Web01            OK                  ERROR

The test seems to work OK for every situation except the VB6 app installed on the web server. The Error I get back is :

-2147024809 - WSDLReader:Loading of the WSDL file failed HRESULT=0x80070057 - WSDLReader:XML Parser failed at linenumber 0, lineposition 0, reason is: The system cannot locate the object specified.

HRESULT=0x1

I get the same error back on Ts01 if I supply a bad WSDL address in the VB6 app. It seems as if the VB6 application on Web01 can't access the web service dll on Web01, which is a big problem.

It may be worth noting that it works on my local developer machine as well, where I have the VB6 app and the web service installed on the same machine.

Why might the VB6 app be having trouble communicating with the web service via SOAPClient when run from the same box that the web service exists?


I used fiddler to inspect the headers of the requests on my local machine calling our dev server. Here's the difference between the browser and SOAPclient requests:

Browser:

GET http://devserver/services/myservice.asmx?WSDL HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, */*
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: devserver
Cookie: SIFR-PREFETCHED=true

SOAPClient (from VB6 App):

GET http://devserver/services/myservice.asmx?WSDL HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
Host: hbhswebnet
Connection: Keep-Alive
Pragma: no-cache

I'm not sure if that information is helpful, but perhaps it is.

+2  A: 

Here's a general pattern:

Q: "x" works in the browser, but fails in a program that's doing the same thing the browser is doing. What's wrong?

A: the program is not doing the same thing the browser is doing.

Browsers explicitly set headers that your program is not setting (especially since you're using the very obsolete SOAPClient). Various pieces of networking equipment and software may look at these headers in deciding how to respond to your requests.

You should look at the network traffic for both cases (browser and program) using Fiddler or something, then look carefully for differences between the way the browser behaves and the way your program behaves. You may then either change the program to be like the browser, or ask your networking people to please reduce security so that your program can access the service.

John Saunders
@John that's great advice, esp. the idea of using Fiddler. I hadn't thought about doing that to examine the request headers. I guess what surprised me most was that it *does work* on one machine, but not the machine that will actually be responsible for making the call.
Ben McCormack
@Ben: based on the headers you posted, I'd ask the networking people about that SIFR-PREFETCHED=true cookie.
John Saunders
A: 

Another thing to look at is the proxy settings in the browser, are you going through a proxy? VB6 picks up some, but not all of the proxy settings from Internet Explorer, but none from any other browser.

If Fiddler doesn't work, you may have to roll up your sleaves and dig into Wireshark, to find out why VB6 isn't communicating.

Another important thing to look at is, is what SOAP Client are you using? (Microsofts antiquated and buggy client, PocketSOAP, something home brewed?) One suggestion might be to write a soap proxy for .Net and then use interop to work with your soap.

Kris Erickson