Client HTTP Status 12031. Server IIS Log 400 w/ Win32 status 121

[MiddEware]

Hi,

Am doing a synchronous HTTP post in a COM component that resides on a Cold
Fusion Web server to another Application Web Server's ASP page via a content
switch. We are experiencing a sporadic problem during peek traffic hours
(during the day) where the Client (i.e. Cold Fusion side) gets a HTTP status
code of 12031 (Internet connection reset error) and the IIS logs on the
Application Server side get a 400 status code (Bad Client Request) and a
Win32 status code of 121 (the semaphore timeout period has expired). The IIS
logs also show a length that is much smaller than the expected payload which
causes us to wonder if chunking is taking place. When this error occurs, it
does not look like the Application server ASP page is even being hit.
Sporadic problem occurs whether base MSXML or MSXML4 is used. Have tried
changing HTTP 1.1 settings on Client/Cold Fusion browser to first use HTTP
1.0 and then HTTP 1.1 but without success. Proxy is not being used. In a
sniff that was done, there appears to be a mixture of HTTP 1.0 and 1.1
traffic flowing between the Client and the Application server.

The Client Cold Fusion Web server runs Windows NT 4.0 SP6 and IIS 4.0. The
Application Web server runs Windows 2000 SP4 and IIS 5.0. (Note-this problem
happened before when the Application Server was running Windows NT SP6A IIS
4.0, but the problem has become exacerbated since it was upgraded to Windows
2000). Also, these Win 2000 servers reside on a different subnet than before.

Any thoughts, comments, or suggestions on this problem would be appreciated.

[David Wang [Msft]]

HTTP communications is an intricate operation between client/server.
Everything is well-calculated and follows rules.

My suspicion is that the client is sending a request to the ASP page which
is malformed with regards to its entity body length -- causing the ASP page
(IIS) to wait for data that never arrives and thus sent an obligatory 400
response back -- and then Cold Fusion side sees the connection reset (IIS
never got the data it was promised before timing out, so the connection is
invalid and should be closed).

I suggest investigating client-side software and make sure that the requests
sent to IIS are always well formed. When you see issues that "only occur
during peak hours", there is probably have some race condition that is
exacerbated only when there's lots of simultaneous traffic, which can cause
two otherwise valid requests to become malformed.

This sort of issue is not easy to track down -- it may help to isolate
possible code paths involved -- for example, narrowing down that the ASP
page is only POST'd to by two different URLs -- so you can concentrate on
just those two URLs under simulated stress conditions using any of the
freely available web-stress tools. To validate my suspicion, you'd do a
network trace of this entire experiment until you find a 400 response --
then you check on its corresponding request to see if it is malformed or
not.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"MiddEware" <***@discussions.microsoft.com> wrote in message news:A37B6A07-2CE8-465B-A1C3-***@microsoft.com...
Hi,

Am doing a synchronous HTTP post in a COM component that resides on a Cold
Fusion Web server to another Application Web Server's ASP page via a content
switch. We are experiencing a sporadic problem during peek traffic hours
(during the day) where the Client (i.e. Cold Fusion side) gets a HTTP status
code of 12031 (Internet connection reset error) and the IIS logs on the
Application Server side get a 400 status code (Bad Client Request) and a
Win32 status code of 121 (the semaphore timeout period has expired). The IIS
logs also show a length that is much smaller than the expected payload which
causes us to wonder if chunking is taking place. When this error occurs, it
does not look like the Application server ASP page is even being hit.
Sporadic problem occurs whether base MSXML or MSXML4 is used. Have tried
changing HTTP 1.1 settings on Client/Cold Fusion browser to first use HTTP
1.0 and then HTTP 1.1 but without success. Proxy is not being used. In a
sniff that was done, there appears to be a mixture of HTTP 1.0 and 1.1
traffic flowing between the Client and the Application server.

The Client Cold Fusion Web server runs Windows NT 4.0 SP6 and IIS 4.0. The
Application Web server runs Windows 2000 SP4 and IIS 5.0. (Note-this problem
happened before when the Application Server was running Windows NT SP6A IIS
4.0, but the problem has become exacerbated since it was upgraded to Windows
2000). Also, these Win 2000 servers reside on a different subnet than
before.

Any thoughts, comments, or suggestions on this problem would be appreciated.

[David Wang [Msft]]

I'm glad you found the problem.

Moving away from WinInet usage on the server is always a good idea -- it was
never designed for usage on the server and performs/scales poorly.

It was probably sufficient to handle low load, but as transaction/requests
grew... it started to be problematic.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"MiddEware" <***@discussions.microsoft.com> wrote in message news:848465F7-4DEF-4E4E-8610-***@microsoft.com...
Hi David,

Based on your feedback, we focused our efforts on the client side of things
and a teammate of mine found the problem. The COM component (which we
inherited) has been running successfully for a number of years on other
client servers and workstations which had us going as to why the cold fusion
server was the only client having this problem. The cold fusion server had
also been ok earlier on, but in the past year was starting to see an
increasing number of client 12031 and 12002 errors particularly during peak
traffic hours. This situation coiincided with transaction growth in the
business segment that the cold fusion server was servicing and may have been
exacerbated by our upgrade to Windows 2000 (HTTP 1.1?).

In short, the COM component was changed to use a server post method instead
of a WinInet post method (a one line change). Our problems have since gone
away. We suspect that the root cause revolves around MS KB article 183110
and
a (default) Cold Fusion timeout setting of 60 seconds for idle Cold Fusion
pages.
(Our users told us that they would get a timeclock for a minute and then get
the 12031).

As a side benefit to this problem, we also uncovered the reason we were
getting a "Method '~' of object '~' failed" error in an earlier version of
our COM component. The earlier version was not handling the 12031 and 12002
status codes and, as such, the reference would get lost resulting in the
method failed error coming back to Cold Fusion.

Once again, thanks for your help in this matter. Take care,

Lee