BizTalk - HTTP Chunked Encoding and proxy servers

I was asked to investigate an issue that one of our clients started experiencing after a new interface went live recently. They had an interface which had been working fine in test environment but started failing periodically after it was put live.

 

The interface uses an HTTP Send port to post large message (containing images) up to a cloud hosted web service.

 

Some messages were being sent successfully but most of them were failing (being rejected by the service with an HTTP error).

 

Everything appeared to be Ok on the BizTalk end (and the configuration seemed to be identical between the live and test environments) and there wasn’t anything obvious as to why some messages were working and some were failing (we even took some of the failed message from live and resent them through the test environment where they worked perfectly)

 

So, we got the service provider involved to see if they can tell why some messages are being rejected. From the limited logging they had enabled on their end, they could tell that the entire HTTP request didn’t seem to be getting through. They couldn’t tell us anymore at that stage without increasing the verbosity of the logging on the service and as it was a multitenant service and they couldn’t do so without affecting other clients as well.

 

We setup a proxy server (using Fiddler) so that we could capture the HTTP requests and see what the messages looked like and they were fine. Complete as they should be. Messages that had failed before even started working while using Fiddler. But without Fiddler they failed again (remember this when you get to the end).

 

We then enabled network tracing (using steps similar to these instructions) which finally showed us the issue. After running a few successful and unsuccessful messages through, and comparing the tracing output we noticed that the unsuccessful messages were using chunked encoding (read about it here more here) and it turned out the service on the receiving end didn’t support it (at least the version that ran in the live environment didn’t). Chunked encoding is enabled by default on the HTTP Send Adapter (as shown in the screenshot below).

 

Enablechunkedencodingoption 

 

As soon as we disabled chunked encoding the interface worked fine and all the messages were being sent successfully.

 

I was still a bit curious why some messages were being “chunked” and other weren’t and then found this very useful note on MSDN which seems to answer the question. It reads:

If the Enable chunked encoding configuration option is enabled, then the HTTP send adapter sends request messages using chunked encoding if the request size exceeds 8 KB. If the HTTP proxy server is used, the HTTP send adapter does not use chunked encoding and always stages the data before sending. The Enable chunked encoding configuration option is enabled by default.

 

So, the reason why some messages seemed to work and others failed was down to size, as the chunked encoding only kicked in if messages were larger than 8KB. Also, chunked encoding isn’t used when a proxy server is setup which is why we didn’t see the issue while using Fiddler.

 

So mystery solved and a lesson learnt. Beware of chunked encoding when using the HTTP Send Adapter and especially when using a proxy server. Check and confirm with the party at the other end of interface if they support chucked encoding and test for it (using message size).

Written by Carlo Garcia-Mier at 00:00

Categories :

0 Comments :

Comment

Comments closed