Specifically, the BizTalk HTTP client attempts to reuse a connection even though the HTTP 1.0 server has not indicated that it supports this option by including the Connection: Keep-Alive header in its initial response.
If simultaneous POST requests are transmitted to the HTTP 1.0 Web server, to be in accordance with the HTTP RFCs, after the first request is processed, the Web server sets the FIN flag on the TCP/IP connection to request closure.
The BizTalk HTTP client does not correctly recognize that the connection should be considered closed and attempts to send another POST request on the same connection.
The semantics of BizTalk Messaging determine that requests may be placed in the Retry Queue and that the underlying TCP/IP transport protocol enter a TCP reset exchange that occurs between the BizTalk client and HTTP 1.0 Web server.
The following text is an example of the initial messages headers that are exchanged, which should determine that there are no persistent connections to be used:
BTS Client Request
POST /a/b/c HTTP/1.1
Host: nnn.nnn.nnn.nnn:pppp
Connection: Keep-Alive
Content-Length: nnn
Content-Type: text/plain; charset="utf-8" Accept: */*....
HTTP 1.0 Server Response
HTTP/1.0 200 OK
Content-Type: text/xml
Servlet-Engine: ...
In extreme situations, transmission of
BizTalk messages may fail and result in messages being placed in the Suspended
Queue.
POST /a/b/c HTTP/1.1
Host: nnn.nnn.nnn.nnn:pppp
Connection: Keep-Alive
Content-Length: nnn
Content-Type: text/plain; charset="utf-8" Accept: */*....
HTTP 1.0 Server Response
HTTP/1.0 200 OK
Content-Type: text/xml
Servlet-Engine: ...