Use Fiddler to analyze WCF for communication requests

In distributed development, there is a basic element that solves the remote object transmission problem through Simple Object Access Protocol (soap). An object sequence can be passed in XML format, for example:

[DataContract]    public class Person    {        [DataMember]        public string Name { get; set; }        [DataMember]        public int Age { get; set; }    }

This type of object will be marked as XML data by WCF during transmission, Because XML can be widely used and is accepted by almost all platforms, therefore, this object may be marked

<Person>
<Name> MyName </Name>
<Age> 25 </Age>
</Person>

In this way, the WCF caller can be easily recognized. In the same way, methods and attributes in classes and classes will be serialized in a standard way, A standard SOAP Data Request package is usually like this:

Code <? Xml version = "1.0"?>
<Soap: Envelope
Xmlns: soap = "http: /// www./2001/12/soap-envelope"
Soap: encodingStyle = "http: // www.www./2001/12/soap-encoding">
<Soap: Header>
...
</Soap: Header>
<Soap: Body>
...
<Soap: Fault>
...
</Soap: Fault>
</Soap: Body>
</Soap: Envelope>

In this way, data is transmitted, and requests can obtain data. We try to use Fiddler to understand the principles.

First, create a simple WCF Service Application

There is a service AddService. svc in this project. One of the methods is that the caller transmits a Person entity to the service, and the service overrides the entity attribute and returns it to the client. This process is a typical example of data editing interaction.

We reference the AddService. svc service in this project and add an UpdataPerson. aspx page for testing.

The code on this page is very simple, that is, to call the service, pass an object into it, and output the Age attribute of the obtained object.

Let's see if it can be called normally.

Here we use Fiddler to monitor this process. When using Fiddler, add the service address localhost. That is:

After the modification is complete, refresh the page and you will find this request in Fiddler.

OK. Now we can analyze the entire call process through the data packets intercepted by Fiddler. Note that the content in Inspectors is the information obtained by monitoring.

We noticed that many of the information captured by Fiddler includes http headers. We are concerned with Raw content.

It contains the Http request header and data contained in the request.

We extracted <s: Envelope> and found that this is the request format of WCF.

Code <S: Envelope xmlns: s = "http://schemas.xmlsoap.org/soap/envelope/%22>
<S: Body>
<GetPerson xmlns = "http://tempuri.org/%22>
<Person xmlns: a = "http://schemas.datacontract.org/2004/07/WCFServiceDemo%22 xmlns: I =" http://www.w3.org/2001/XMLSchema-instance%22>
<A: Age> 23 </a: Age>
<A: Name> LeonWeng </a: Name>
</Person>
</GetPerson>
</S: Body>
</S: Envelope>

We found that this "envelope" contains the information required by the WCF request, including the service name and two fields of the Person object. After this XML file is available, the WCF server can construct the Person class:

Person person = new Person () {Name = "LeonWeng", Age = 23 };

Then, change the attributes of the class and send it back to the client:

In Raw, we can also find an envelope:

Code <S: Envelope xmlns: s = "http://schemas.xmlsoap.org/soap/envelope/%22>
<S: Body>
<GetPersonResponse xmlns = "http://tempuri.org/%22>
<GetPersonResult xmlns: a = "http://schemas.datacontract.org/2004/07/WCFServiceDemo%22 xmlns: I =" http://www.w3.org/2001/XMLSchema-instance%22>
<A: Age> 25 </a: Age>
<A: Name> LeonWeng </a: Name>
</GetPersonResult>
</GetPersonResponse>
</S: Body>
</S: Envelope>

 

 

23 has been changed to 25 by the server, but the difference is that the tag is changed to the output:

In the following article, we will learn more through Fiddler.