Fun with web-services and unqualified elementFormDefault

Recently I was participating in writing client for document-style binding web-service. This is the first time I saw such wsdl in the field, so I immediately wrote a small test application in VS.NET 2005. Although invoke appears to be working normally, I got null response instead of some actual data. I spent a whole week blaming authors of the web service, but they convince me that the problem was on the client side. It was quite difficult to intercept soap messages, because they were using https, but I found an interesting post how you can get them from SoapHttpClientProtocol. Using this small hack, I was able to observe the resulting envelope, that did contains response, which looks legitimate. But at the end in the corresponding C# object I still got nulls. The wsdl begins with the following declaration:

<wsdl:definitions name="testservice"
     targetNamespace="http://www.testservice.com">
<wsdl:types>
 <xsd:schema elementFormDefault="unqualified"
      targetNamespace="http://www.testservice.com/test">
   <xsd:element name="response">
     <xsd:complextype>
       <xsd:sequence>
         <xsd:element name="ident" type="xsd:string">
         <xsd:element name="number" type="xsd:string">
       </xsd:sequence>
     </xsd:complextype>
....

Visual Studio generate me a corresponding class called response with 2 properties, that has Unqualified System.Xml.Serialization.XmlTypeAttribute. Apparently, Axis on the server side was sending me a message, where both ident and number was in http://www.testservice.com/test namespace, which contradicts with the schema definition above. This was the reason why deserialization from XML does produce nulls. At least this time Microsoft proofs to support standards better than Apache Foundation :)

Accessing web services over https using own-made certificate

In most of our products we are extensively using web-services. Some of them are relaying on SSL to encrypt data streams. It works pretty good from the .NET Framework client if corresponding server certificate is issued by certification authority known by Windows, but if you want some $$ in your budget, you probably will generate the certificate by yourself. When you are trying to access such service from C# program, you will get "The underlying connection was closed: could not establish trust relationship for SSL/TLS secure channel". There is a good post about how to make it work by Jan Tielens, but for .NET Framework 2.0 there is even simpler solution - put the line below somewhere during initialization of your application

System.Net.ServicePointManager.ServerCertificateValidationCallback +=
                               delegate { return true; };

Be careful when you are specifying hosts in defaultProxy/bypasslist

In our company all http traffic comes through squid. It is well known that squid has own opinion what is right and what is wrong in http. One good example is that all requests, originated from squid has “HTTP1.0” in header even if originally it was 1.1 Also squid hates DIME, so if you want to use external web-service that utilize DIME, you have to bypass squid. .NET Framework has quite good facilities in specifying proxy settings for the application. In fact when you are specifying hosts in <bypasslist>, you can use regular expressions. I was really surprised when once it doesn’t work in my application. I spent a couple of hours trying to track down what is wrong with the program, and finally discovered that my DIME requests was not bypassing proxy as intended. It appears that I was using ip address in <bypasslist> and domain name in the url of web service. So when .NET framework is trying to much them, it does not perform dns-lookup. Be aware of this!