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.
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.