FIX: An HTTP Protocol Violation Occurs When BizTalk Server Communicates with an HTTP 1.0 Server (320370)
The information in this article applies to:
- Microsoft BizTalk Server 2002
- Microsoft BizTalk Server 2000
This article was previously published under Q320370 SYMPTOMS When you configure BizTalk Server to communicate to an HTTP
1.0 server, the BizTalk HTTP client does not honor the protocol requirements
that are specified in the published HTTP RFCs with regard to persistent
connections behavior. 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. CAUSE Performance optimizations that were made in BizTalk Server
implement a cache for TCP connections, which inadvertently resulted in
connections being inappropriately reused when the overlying transport protocol
was HTTP 1.0. RESOLUTIONService Pack Information To resolve this problem, obtain the latest
service pack for Microsoft BizTalk Server 2002. For additional information,
click the following article number to view the article in the Microsoft
Knowledge Base: 815781 How to Obtain the Latest BizTalk Server 2002 Service Pack Hotfix InformationA supported fix is now
available from Microsoft, but it is only intended to correct the problem that
is described in this article. Apply it only to computers that are experiencing
this specific problem. This fix may receive additional testing. Therefore, if
you are not severely affected by this problem, Microsoft recommends that you
wait for the next that contains this hotfix. To resolve this problem
immediately, contact Microsoft Product Support Services to obtain the fix. For
a complete list of Microsoft Product Support Services phone numbers and
information about support costs, visit the following Microsoft Web site: NOTE: In special cases, charges that are ordinarily incurred for
support calls may be canceled if a Microsoft Support Professional determines
that a specific update will resolve your problem. The typical support costs
will apply to additional support questions and issues that do not qualify for
the specific update in question. STATUSMicrosoft has confirmed that this is a bug in the Microsoft
products that are listed at the beginning of this article.
This problem was first corrected in Microsoft
BizTalk Server 2002 Service Pack 1.REFERENCES The following text is from IETF RFC 2616: Section 8.1.2.1:
Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled.
Section 19.6:
And we would expect HTTP/1.1 clients to:
* recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
* understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.
For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described in section 19.7.1 of RFC 2068 [33]. In RFC 1945, Connection: Keep-Alive is a "common extension" to a 1.0 implementation. Closing the
connection after the response is also the expected behavior in the absence of
other signaling.
Modification Type: | Minor | Last Reviewed: | 10/12/2005 |
---|
Keywords: | kbHotfixServer kbQFE kbBizTalk2002SP1fix kbbug kbfix KB320370 kbAudDeveloper |
---|
|