33

I am a DBA, not a developer, so forgive me if this is a silly question. But we are having issues with a SQL Server 2005 Web Service end point. On the local network I am able to add the reference in Visual Studio 2010 with out any issues. It uses digest as the authentication scheme.

However, when anyone tries to add the web reference on another network, such as a developer in New Zealand (we are in Dayton, OH USA) he receives this error:

There was an error downloading 'http://server.domain.net:1280/release-single-address?wsdl'. The request failed with HTTP status 505: HTTP Version not supported. Metadata contains a reference that cannot be resolved: 'http://server.domain.net:1280/release-single-address?wsdl'. The remote server returned an unexpected response: (505) HTTP Version not supported. The remote server returned an error: (505) Http Version Not Supported. If the service is defined in the current solution, try building the solution and adding the service reference again.

Again, this works in Visual Studio as Right Click add Reference -> Advanced -> Add Web Reference when done on the local subnet as the server.

When done on any other network the service does not import. We have tried it w/o any proxy. There is a cross domain trust involved but that does not seem to be the issue as the error occurs using accounts from either domain. When I download the raw XML to my hdd I can use that to create the web reference. I believe firmly this is some sort of transport layer issue, such as a proxy, but captures when the proxy server settings are disabled are not conclusive.

Angelo Fuchs
  • 9,825
  • 1
  • 35
  • 72
Robert Kaucher
  • 1,841
  • 3
  • 22
  • 44
  • Can you try browsing to the web service from the other location, using a web browser? What errors do you see? – Garett Oct 14 '10 at 16:55
  • Browsing the URL via IE in either location seems to work fine. We get a massive amount of XML. – Robert Kaucher Oct 14 '10 at 20:54
  • Just on a side not I have recreated this as a WCF service and we are still having issues. I think it is something network related. – Robert Kaucher Oct 21 '10 at 00:52
  • 1
    have the user test do a telnet port test server.domain.net:1280 via telnet server.domain.net 1280. Also have them test a tracert server.domain.net and see what results you get. The telnet may let you know whether the port is blocked. when you browsed the URL did you use the port number? I imagine so, but just checking – john.da.costa Mar 30 '11 at 03:24
  • 3
    John, thanks for the reply. We think this was caused by a proxy server. We changed the service to a WCF with binary messaging and it started working fine. I did not post it as an answer as totally giving up and doing something else is not really a solution... – Robert Kaucher Mar 30 '11 at 12:24
  • 3
    I'd be wary about continuing development using the SQL Server web services end points - this feature was only present in SQL Server 2005 which hits end of life in mid-2014. –  Jan 09 '13 at 15:01
  • I agree completely and that was actually what I argued regarding that choice at the time. We have completely changed our web services strategy to WCF and ASP.NET MVC Web API. – Robert Kaucher Jan 09 '13 at 16:11
  • FYI, this is very likely a firewall issue. – RBarryYoung Jan 11 '13 at 14:18
  • In our case it was a Squid-based proxy server. But certainly a firewall could cause the same problem. – Robert Kaucher Jan 11 '13 at 14:33
  • You should also post the wsdl – freedev Jan 24 '13 at 08:28

4 Answers4

5

Today, years after I posted this question, we finally found the answer to this question. It was not a Squid proxy server as we had come to believe. We continued experiencing issues like this with various web services/sites. The last straw was when we finally needed to deploy an SVN server that was used by multinational software engineering teams. Every single member of the different Ops teams we spoke to swore to us there was nothing between the sites that could break our services.

By a stroke of luck the company's Chief Information Security Officer was visiting our site and a colleague happened to run into him and asked about the issues we were having and what might be the cause of it. He said immediately that there were Riverbed appliances doing caching and layer 7 inspection on all WAN traffic. We finally managed to catch these devices in the act of attempting to "normalize" HTML and XML and we were able to perform a capture of data coming from a machine in New Zealand. We performed a diff on HTML pages that were served as well as XML coming from a web service to compare how it looked on the local network vs. across the WAN. In the pages/XML that were being served across the WAN the closing tags were inserted that were not needed or that actually made the XML malformed. Some tags were even commented out entirely if the appliance didn't know what to do with them. And the smoking gun? A custom header...

X-RBT-Optimized-By: cch-riverbed-1 (RiOS 6.5.6a) SC

"Optimized" You keep using that word, but I do not think that it means what you think that it means.

Robert Kaucher
  • 1,841
  • 3
  • 22
  • 44
  • Is there a way to work around this by letting the device know that I do not want my XML molested? – wilx Sep 27 '13 at 11:57
  • I would assume that admins should be able to white list certain IP addresses or host names. We opted to run services over SSL before we were able to finally determine the root cause. We have simply carried this strategy forward. – Robert Kaucher Sep 28 '13 at 04:26
1

I'm not a pro of SOAP with VS but it may be that version of SOAP is incompatible with sql server 2005?

If I recall correctly, there is two versions of SOAP: 1.1 and 1.2.

Nico
  • 6,395
  • 4
  • 25
  • 34
1

Check the HTTP GET command format is correct?

HTTP GET http:// mydomain.com HTTP/1.1\

note there is a SPACE between 'http://' and 'mydomain.com'. The server can not match this format. The result is 505

celeron533
  • 21
  • 4
1

I am not sure but, I think you should check your firewall or your IIS configuration.

Ali
  • 808
  • 1
  • 6
  • 11