Can the Client cause a response code of 0.

[Ray]

Hi-

I was given a Fiddler trace (saz file) that illustrates a problem being experienced from a network in Eurorpe. This one user is reporting slow page loads.  Really really slow page loads.

The trace shows some requests returning a "result" of 0 rather than 200 response code, but most are returning 200.  This is the only known issue from over 40 other client work stations.  My immediate thought is to lay the blame on this single client instance.  But the trace (snippet below) is showing that the request was made and the server has received it.  Which makes the server look guilty here.  Except, I've not once been able to repro this issue from the US.  And 40+ other clients are not reporting the same issue.   I am trying to find out if, despite the server having received the request as shown, could this possibly be a client side issue? 

Request Count:   1
Bytes Sent:      1,807        (headers:1,025; body:782)
Bytes Received:  60        (headers:60; body:0)

ACTUAL PERFORMANCE
--------------

This traffic was captured on Thurs

ClientConnected:    23:30:52.348
ClientBeginRequest:    23:30:55.362
GotRequestHeaders:    23:30:55.362
ClientDoneRequest:    23:30:55.364
Determine Gateway:    0ms
DNS Lookup:         0ms
TCP/IP Connect:    0ms
HTTPS Handshake:    0ms
ServerConnected:    23:30:52.401
FiddlerBeginRequest:    23:30:55.364
ServerGotRequest:    23:30:55.364
ServerBeginResponse:    00:00:00.000
GotResponseHeaders:    00:00:00.000
ServerDoneResponse:    00:00:00.000
ClientBeginResponse:    00:00:00.000
ClientDoneResponse:    00:00:00.000


RESPONSE BYTES (by Content-Type)
--------------
~headers~: 60


Thanks in advance-

[Eric Lawrence]

Hi, Ray--

Generally speaking, no, if the server has received the request then it's unlikely to be a client bug, although certainly there could be a problem somewhere along the network route from the client to the server.

However, are you sure that the server really got the request? The timer name can be misleading; it really reflects the time at which the client finished writing the request to the network, but that doesn't mean that the server actually received it.

If you look at the Inspectors, what is the text in the TextView response inspector for the failing request?

Do you have a NetMon or Wireshark log of the failing traffic?

Regards,
Eric Lawrence
Telerik

 

 

[Ray]

Hi and thank you for replying.

I think that does point me to a next step for troubleshooting. We didn't have tcpdump running on the server at the time but we can probably run similar test again using that method in addition to capturing from the client side. From the Inspectors tab the TextView is empty.
I've gone through server logs to see if i could match the request but couldn't so I am inclined to believe that something in the transmission along the path to the server got mangled.

Thanks again for the help and I hope to be able to return here with a solution of the issue in a future post.

-Ray

[Eric Lawrence]

Hi, Ray--

Very interesting:

Bytes Received:  60        (headers:60; body:0)

...suggests that there should be some header information; if you look at the RAW or HEADERS tab, is there anything of interest there?

Regards,
Eric Lawrence
Telerik