Posted by codinglifestyle in ASP.NET, CodeProject, IIS.
Tags: 400, Bad Request, iis7.5, soap, SoapExtension, web service, web.config, xml
You may have found this post if you were searching for:
- HTTP 400 Bad Request web service
- Response is not well-formed XML web service
- System.Xml.XmlException: Root element is missing web service
- SoapExtension impacting all web services
Yesterday I was debugging an inconsistent issue in production. Thankfully we could track trending recurring errors and began to piece together all incoming and outgoing webservices were being negatively impacted for unknown reasons. This was creating a lot of pressure as backlogs of incoming calls were returning HTTP 400 Bad Request errors. Outgoing calls were silently failing without a facility to retrigger the calls later creating manual work.
We suspected SSO or SSL leading us to change settings in IIS. Being IIS 7.5 this touched the web.config which recycles the app pool. Every time a setting in IIS was changed or an iisreset was issued it seemed to rectify the situation. But after an indeterminate amount of time the problems would resurface.
The culprit ended up being a SoapExtension. The SoapExtension modifies the soap header for authentication when making outgoing calls to a java webservice.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header>
<h:BasicAuth xmlns:h="http://soap-authentication.org/basic/2001/10/"
SOAP-ENV:mustUnderstand="1">
<Name>admin</Name>
<Password>broccoli</Password>
</h:BasicAuth>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:echoString xmlns:m="http://soapinterop.org/">
<inputString>This is a test.</inputString>
</m:echoString>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
It does this with a dynamically loaded (that bit was my fault and made it a complete bitch to debug) SoapExtension taken from a legacy command line util which did this every 5 minutes:
This existed simply because nobody could figure out how to call the webservice directly within the web application. Once incorporated when the web service was called, perhaps hours from an iisreset, the SoapExtension is dynamically loaded. The bug was, even though it was coded to not affect anything but Vendavo, the checks performed were performed too late and therefore all web services, incoming and outgoing, were impacted.
Previously the check was in the After Serialize message handler. The fix was to return the original stream in the ChainStream. The hard part was knowing what webservice was making the call before ChainStream was called. The check was moved to:
public overrides void Initialize(Object initializer)
The initializer object was tested setting a flag used in ChainStream to determine which stream was returned.
So lesson learned, beware SoapExtensions may impact all soap calls. While you can specify a custom attribute to limit the extension to web methods you publish you cannot use this filtering mechanism on webservices you consume. This means you must self-filter or risk affecting all incoming and outgoing web services unintentionally.
Also, dynamically loading a setting which belongs in the web.config was a dumb idea which delayed identification of the problem. Now we use this:
<system.web>
<webServices>
<soapExtensionTypes>
<add type="SBA.Data.PMMSoapExtension, SBA.Data" priority="1" group="High" />
</soapExtensionTypes>
</webServices>
</system.web>
Ref:
http://www.hanselman.com/blog/ASMXSoapExtensionToStripOutWhitespaceAndNewLines.aspx
http://msdn.microsoft.com/en-ie/magazine/cc164007(en-us).aspx
Posted by codinglifestyle in ASP.NET, C#.
Tags: entity, proxy, serialization, webservice, xml, XmlSerializer
If you are looking at this page I would suggest you ask yourself the following questions:
- Is the architecture of my software broken? Why am a referencing a class on either side of a webservice?
- Are web services really necessary in this situation?
My answers are yes, it is broken, and yes, there is an egrigious use of web services throughout. Unfortunately, this product is many years old and I have to do what the customer asks. So here I have an entity class which is not a simple container for data. It contains additional methods and logic. This entity is populated by the database and then forked over by webservices. However, the UI layer also needs access to the additional methods and logic in the entity. The WSDL generated proxy class does not contain these methods or logic; just a simple representation of the public properties of the class with straight gets and sets.
The challenge then, is to serialize the web service proxy class back to the entity class. Once this is done, I will have access to the additional methods and logic I need. We can do this by using what web services use, XML serialization. Its a fast way of getting our data from the proxy class back to XML. Then deserialize the XML back to the entity class.
///
/// Serialize the data from an object of Type_A to a new object of Type_B
///
///The Type_A object containing the data to serialize
///The Type_B to be created and deserialized with the Type_A object
///An object of Type_B
static object SerializeObjects(object oSource, Type tDestination)
{
XmlNoNamespaceWriter xw = null;
Object oDestination = null;
try
{
//Prepare to convert XML entity to XmlNoNamespaceWriter
MemoryStream ms = new MemoryStream();
xw = new XmlNoNamespaceWriter(ms, Encoding.UTF8);
XmlSerializer xsA = new XmlSerializer((oSource.GetType()));
//Serialize web service xml data to xml stream
xsA.Serialize(xw, oSource);
//Deserialize stream to entity actual
XmlSerializer xsB = new XmlSerializer(tDestination);
xw.BaseStream.Position = 0;
oDestination = (WSEntityTest.Entity)xsB.Deserialize(xw.BaseStream);
}
catch
{ }
finally
{
//Close the stream
if (xw != null)
xw.Close();
}
return oDestination;
}
So what we are doing is using a memory stream and XmlTextWriter to contain the XML. The XmlSerializer serializes the proxy class to the stream. If you wanted to look at the resulting XML, you could use an XmlDocument to load the stream and take a look. If we do that, we will notice a small problem. Every child element will contain a namespace attribute (xmlns). This will throw a spanner in the works when deserializing the data to our entity class. Basically what the namespace is telling the XmlSerializer is the data doesn’t belong in our entity class so it will skip it. It’s just doing its job because technically we shouldn’t be serializing data from the class of type A to a class of type B. However, this is exactly what we need to do. To work around this, I looked high and low for a simple way of turning off the namespace (in .NET v2.0). Nothing simple turned up, hence the use of XmlNoNamespaceWriter which is derived from XmlTextWriter. The implementation of this class is shown below:
public class XmlNoNamespaceWriter : System.Xml.XmlTextWriter
{
bool m_bSkipAttribute = true;
public XmlNoNamespaceWriter(System.IO.Stream writer, System.Text.Encoding encoding) : base(writer, encoding)
{
}
public override void WriteStartElement(string sPrefix, string sLocalName, string sNS)
{
base.WriteStartElement(null, sLocalName, null);
}
public override void WriteStartAttribute(string sPrefix, string sLocalName, string sNS)
{
//If the sPrefix or localname are “xmlns”, don’t write it.
if (sPrefix.CompareTo(“xmlns”) == 0 || sLocalName.CompareTo(“xmlns”)==0)
{
m_bSkipAttribute = true;
}
else
{
base.WriteStartAttribute(null, sLocalName, null);
}
}
public override void WriteString(string sText)
{
//If we are writing an attribute, the sText for the xmlns
//or xmlns:sPrefix declaration would occur here. Skip
//it if this is the case.
if(!m_bSkipAttribute)
{
base.WriteString(sText);
}
}
public override void WriteEndAttribute()
{
//If we skipped the WriteStartAttribute call, we have to
//skip the WriteEndAttribute call as well or else the XmlWriter
//will have an invalid state.
if(!m_bSkipAttribute)
{
base.WriteEndAttribute();
}
//reset the boolean for the next attribute.
m_bSkipAttribute = false;
}
public override void WriteQualifiedName(string sLocalName, string sNS)
{
//Always write the qualified name using only the
//localname.
base.WriteQualifiedName(sLocalName,null);
}
}
I found this class here, and modified it slightly to use a stream rather than a file. So now we get past our namespace issue and the serializer won’t be confused by the namespaces. Now all we need is a second XmlSerializer created with our entity type. This will deserialize the stream in to a new instance of our entity class. The usage of the method is shown below:
//Retreive the WebService proxy class
localhost.Service1 svc = new Client.localhost.Service1();
localhost.Entity xmlEntity = svc.HelloWorld();
//Serialize the proxy class to a new entity class
Entity entity = (Entity) Program.SerializeObjects(xmlEntity, typeof(Entity));
Coding Lifestyle 