fiddler.network.readresponse.failure Fiddler handling of WSAECONNRESET

[mulac]

Hi,

I'm receiving a WSAECONNRESET in my application (I'm forcefully
recycling the IIS 6 worker process to simulate potential scenarios
that we are encountering in the field). If I perform the same IIS app
pool recycle with fiddler running in the background (fiddler2 is
configured as a reverse proxy that my client send requests to which
then get bound to the IIS server) I'll see the following in the
fiddler log, however the transaction is successful (HTTP 200 returned
from webservice POST)

fiddler.network.readresponse.failure> Session #778 raised exception An
existing connection was forcibly closed by the remote host

The statistics of the transfer are here. For the life of me I cannot
figure out how fiddler is able to recover in this scenario. I've
closed and re-opened the socket, tried simply calling recv in a loop
(ignoring the socket error), but I can never get the transaction to be
successfull. I don't want to re-send the transaction and I don't
believe fiddler is doing such a thing in this scenario. I'm trying to
understand what fiddler2 is doing under the hood in this scenario???
In my code the socket recv call (after sending the post) is always
getting the WSAECONNRESET failure after I perform the app pool recycle
(I'm sitting in a loop sending the same transactions over and over
before recycling the app pool).

Request Count: 1
Bytes Sent: 650
Bytes Received: 754

ACTUAL PERFORMANCE
--------------
ClientConnected: 18:16:58.848
ClientBeginRequest: 18:16:58.848
ClientDoneRequest: 18:16:58.848
Gateway Determination: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 18:17:23.801
FiddlerBeginRequest: 18:17:23.801
ServerGotRequest: 18:17:23.801
ServerBeginResponse: 18:17:24.458
ServerDoneResponse: 18:17:24.458
ClientBeginResponse: 18:17:24.458
ClientDoneResponse: 18:17:24.458

[EricLaw]

First, right-click on the session and look at the text in the
properties dialog. Is there anything interesting there?

Now, backing out a bit, I'm not fully sure I understand what your
scenario is. If Fiddler is reusing an existing connection to a server,
and that connection resets without accepting the new request, then
Fiddler will try again on a new connection to the server. If that new
connection fails, then Fiddler will return a failure to the client
indicating that the server isn't up.

[mulac]

Nothing interesting that I don't see with other sessions. Regarding
your repsone above;

"If Fiddler is reusing an existing connection to a server, and that
connection resets without accepting the new request, then Fiddler will
try again on a new connection to the server. If that new connection
fails, then Fiddler will return a failure to the client indicating
that the server isn't up"

So if am correct in your understanding. Fiddler has a TCP connection
to the server that it's re-using. My application sends a post via
fiddler (since it's confgured as a reverse proxy to a web server) and
a WSAECONNRESET is returned to Fiddler. In this secneario Fiddler re-
opens a new connection and trys again. If this attempt fails, an
error is returned to the client otherwise the successfull status
information is returned.

Did I understand this correctly? If so, then this is why they are
indicating that this error goes away when they hook up fiddler as a
reverse proxy to obtain debug info.

Logfile has this;

fiddler.network.readresponse.failure> Session #778 raised exception An
existing connection was forcibly closed by the remote host

Session information in properties dialog has this.

SESSION STATE: Done.
Request Entity Size: 332 bytes.
Response Entity Size: 467 bytes.

== FLAGS ==================
BitFlags: [ClientPipeReused] 0x8
X-RESPONSEBODYTRANSFERLENGTH: 467
X-PROCESSINFO: pctest_nt:5276
X-SERVERSOCKET: REUSE ServerPipe#342
X-CLIENTIP: 127.0.0.1
X-HOSTIP: 127.0.0.1
X-EGRESSPORT: 1246
X-CLIENTPORT: 1238

== TIMING INFO ============

ClientConnected: 18:16:58.848
ClientBeginRequest: 18:16:58.848
ClientDoneRequest: 18:16:58.848
Gateway Determination: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 18:17:23.801
FiddlerBeginRequest: 18:17:23.801
ServerGotRequest: 18:17:23.801
ServerBeginResponse: 18:17:24.458
ServerDoneResponse: 18:17:24.458
ClientBeginResponse: 18:17:24.458
ClientDoneResponse: 18:17:24.458

Overall Elapsed: 00:00:25.6098667

The response was buffered before delivery to the client.

== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state
at the time of the request.

> > ClientDoneResponse:     18:17:24.458- Hide quoted text -
>
> - Show quoted text -