.net core web api receiving special character in JSON Request Body

Question

Hi There,

I have two servers(Azure Application Service) one is with .Net Framework(ServerA) and another server .Net Core(ServerB) and a Gateway between them. Server A is sending a request to server like this code below, and the request pass through the Azure Application Gateway:

Server A Code:

string bodyInJSONFormat = new JavaScriptSerializer().Serialize(ListOfFields);

HttpRequestMessage objRequest = new HttpRequestMessage(HttpMethod.Post, endPoint);
objRequest.Headers.Add("Key", APIKEY);
objRequest.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
objRequest.Content = new StringContent(bodyInJSONFormat, Encoding.UTF8, "application/json");
.. somecode here then
await client.SendAsync(objRequest);

Server B, is a .Net Core web api that receives the JSON content.

Endpoint:

[HttpPost("test/testa/testaaa")]
public async Task<IActionResult> testEndpoint([FromBody] MyObjectTest pBody)

The issue is that I am receiving the message: Object reference not set to an instance of an object. because I am trying to use the pBody and that is actually null.

Here is what I know/did:

• This issue doesn't happen all the time, if I do many tests it works. Customers are using this endpoint and mostly of the time there is no issue.
• On Server B, I logged the JSON after I serialized, and I don't see anything on the log.(I am wondering if the log system is removing the special character...)
• I added a handler in Server B, because I want to make sure that I am receiving a JSON before .Net parses into the MyObjectTest, and the Log actually shows that I am receiving a JSON but with special character and the JSON is not properly formatted, missing a double quotes in the end. Here is a screenshot of the special character. This special character shows only when I receive null in my object, which I believe is causing the error.
• 

My questions are:

• 1. Is it possible to enable the Azure Application Insights to check the Request Body and Response Content?
• 2. Am I missing something to convert an Object into JSON and send that to another server?
• 3. Since mostly of the time is working, could it be a performance issue?
• 4. Is there any configuration in .Net Core Web Api that could be affecting this?

[Updated on March 17 - 2022]

• I added the code that @AgaveJoe said, and didn't work, I still have the issue.

I tried two more changes: 1 - I tried to dispose the HttpRequestMessage every time, that didn't work either. 1 - I tried to call the other server without pass the Gateway, and that actually worked. Some how when I do a swap and the code has the domain for the gateway, I start to see the error. If I don't use the gateway and add the domain that goes straight to the app service, the problem doesn't happen at all.

My next steps now is to analyze the gateway rules and try to understand how that could be possible. Since mostly of the requests I don't have any issue. If you guys have any idea please let me know, I would appreciate that.

[Updated on April 12 - 2022]

• Azure Support Engineer asked me to enable a Network Trace in the Server A, so I did and I could see that the http content(Json) had no special character. In order to do this test I have to enable the request to be HTTP instead of HTTPs.
• Waiting for more further instructions, I sent the network trace to azure.

Answer 1

@Rogerio Honorio - Hope you are doing great and thanks for raising the support ticket with us.

I see that our support engineer has provided an update what might be causing the issue and below are some of the pointers that you can take a look into:

1. In the way that the App Service architecture is built, there is L7 LB on it that catches the requests before sending it to our AppGw, I wanted to see if the issue would happen if the request was sent through something like postman instead of the AppService.
2. The fiddle capture will give us an accurate capture from the source, based on what I said above the logging you see on the Azure portal comes from the web workers before sending the traffic to the front end, a fiddle capture on a VM making the request would give us more insight, when I said L7 LB, I meant the front end load balancer built in the App Service architecture, not the AppGw.
3. If we take a network trace on the AppGw, it's a process that keeps ongoing, the more we leave it the bigger the data is going to get, ideally, we would be on a call performing several tests until we get the issue and have it captured on our logs.
4. Another thing we could do is to enable Gateway trace logs, but as I said previously it's not recommended to leave it running for a long time since it can affect performance.
5. We cannot guarantee that the Trace logs will show something that can help us confirm the behaviour of the AppGw, same thing with the Network trace logs, although the network trace logs are most likely to give us a better insight on how the AppGw receives the packets.
6. Unfortunately, to involve the development team we need some form of trace that shows the AppGw changing the characters, since the way the AppGw is built, it is very rare to see something being changed on a requestBody, so the development team would ask for us some form of test like the ones I've been mentioning above. If you could do the test on a VM sending the request through POSTMAN and the issue still happens, it would give us the idea that no matter the type of source the issue would happen as long as the AppGw is in the picture, but we need to get that test first.

But i see that you mentioned you would want to archive his issue for now, since your developers have other priorities to look into. Please let us know if you would like to re-open the ticket in the future and we can do so for you..

Hope this helps. and please feel free to reach out if you have any further questions.

---

If the above response was helpful, please feel free to "Accept as Answer" and "Upvote" the same so it can be beneficial to the community.