Fiddler] ReadResponse() failed: The server did not return a response for this request. Server returned 0 bytes.

2 Answers 1862 Views
FiddlerCore
Anuj
Top achievements
Rank 1
Anuj asked on 23 Apr 2015, 10:15 PM

This issue was reported by someone using my app which user fiddler core but the issue also repro's on standalone fiddler.

Launch fiddler and go to a media server link like 

http://www.media-server.com/m/p/fbqsmu6b

The response returned is Fiddler] ReadResponse() failed: The server did not return a response for this request. Server returned 0 bytes.

I would like to know if there is a way to work around this issue using fiddler core.

Thanks,

Anuj

sirasit tv
Top achievements
Rank 1
commented on 09 Jul 2017, 07:15 AM

-
sirasit tv
Top achievements
Rank 1
commented on 15 Jul 2017, 01:06 AM

-
sirasit tv
Top achievements
Rank 1
commented on 15 Jul 2017, 01:11 AM

[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes
sirasit tv
Top achievements
Rank 1
commented on 28 Jul 2017, 06:59 AM

The error message you're showing below means exactly what it says-- The server accepted the request and then closed the connection without sending any bytes back. It's possible that this happened because the server didn't like some aspect of the request (e.g. the IP address from which the request was sent, the User-Agent header on the request, etc) or because the server is buggy, or the network connection failed, etc. A properly functioning server *should* return an error message in the event that it deliberately does not want to provide a resource, but not all do so.
sirasit tv
Top achievements
Rank 1
commented on 28 Jul 2017, 07:03 AM

...

 

sirasit tv
Top achievements
Rank 1
commented on 28 Jul 2017, 07:04 AM

The error message you're showing below means exactly what it says-- The server accepted the request and then closed the connection without sending any bytes back. It's possible that this happened because the server didn't like some aspect of the request (e.g. the IP address from which the request was sent, the User-Agent header on the request, etc) or because the server is buggy, or the network connection failed, etc. A properly functioning server *should* return an error message in the event that it deliberately does not want to provide a resource, but not all do so.

 

sirasit tv
Top achievements
Rank 1
commented on 28 Jul 2017, 07:04 AM

.
sirasit tv
Top achievements
Rank 1
commented on 28 Jul 2017, 07:06 AM

.
sirasit tv
Top achievements
Rank 1
commented on 29 Jul 2017, 11:30 PM

[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes
sirasit tv
Top achievements
Rank 1
commented on 29 Jul 2017, 11:33 PM

[Fiddler] ReadResponse () failed: The server did not return a complete response for this request. Server returned 0 bytes

 

sirasit tv
Top achievements
Rank 1
commented on 29 Jul 2017, 11:34 PM

[Fiddler] ReadResponse () failed: The server did not return a complete response for this request. Server returned 0 bytes
Rajendra
Top achievements
Rank 1
commented on 09 Jul 2020, 02:46 PM

I have kind of same issue. Client application sends some byte during upload a file but after return from server it is always less and then error occurred or disconnect from the server. This issue is in Unity Client (OnBase Document Management System). But again when the file size is less like around 3MB, this works well but fails if higher mb of file size (I tested around 5MB files and failed). This is also not happening in all PCs.
Eric R | Senior Technical Support Engineer
Telerik team
commented on 09 Jul 2020, 07:10 PM

Hi Rajendra,

I am not sure that Fiddler could cause such an issue unless there is something specific in the Rules. My first guess is the server limits upload size which is common. Although, this wouldn't make sense if it isn't happening on all PC''s.

To troubleshoot this can you provide the following information? 

  1. Fiddler Log Output.
  2. An Archive of the problematic sessions.
  3. Screenshots or errors that you think may help provide additional information.
  4. A description of the different PC's you have tried this on, e.g OS, Browser, etc.

Once I have the above information, I can try to provide a better approach to troubleshooting.

Please let me know if you need any additional information. Thank you for using the Fiddler Forums.

Regards,


Eric R | Senior Technical Support Engineer
Progress Telerik

Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
Our thoughts here at Progress are with those affected by the outbreak.

2 Answers, 1 is accepted

Sort by
0
Eric Lawrence
Telerik team
answered on 24 Apr 2015, 04:19 PM
Hello, Anuj--

If I launch Fiddler and go to http://www.media-server.com/m/p/fbqsmu6b in my browser, I don't see any errors of any sort.

The error message you're showing below means exactly what it says-- The server accepted the request and then closed the connection without sending any bytes back. It's possible that this happened because the server didn't like some aspect of the request (e.g. the IP address from which the request was sent, the User-Agent header on the request, etc) or because the server is buggy, or the network connection failed, etc. A properly functioning server *should* return an error message in the event that it deliberately does not want to provide a resource, but not all do so.

Fiddler and FiddlerCore do not have any way to magically force a server return content if the server does not.

Regards,
Eric Lawrence
Telerik
 

See What's Next in App Development. Register for TelerikNEXT.

 
Anuj
Top achievements
Rank 1
commented on 28 Apr 2015, 08:56 PM

Thanks Eric for your response. It looks like the issue repro's from some machines and does not repro on others. I haven't been able to find the difference yet but thought I will post the status to see if you have any debugging ideas.

This is an external url so I don't have visibility into the server logs. However, on the client side, I don't see any changes to User-Agent, etc. Below is the request and response.

Request

 GET http://www.media-server.com/m/p/fbqsmu6b HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: www.media-server.com
DNT: 1
Connection: Keep-Alive

Response

HTTP/1.1 504 Fiddler - Receive Failure
Date: Tue, 28 Apr 2015 20:54:01 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Cache-Control: no-cache, must-revalidate
Timestamp: 13:54:01.067

[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 0 bytes.

 

Eric Lawrence
Telerik team
commented on 28 Apr 2015, 09:44 PM

Hi, Anuj--

You might wish to look at the Session's Properties (Right-click in the list and choose Properties) to see if, for instance, the same IP address is being used on affected and unaffected machines. It would also be interesting to see the timings to understand if the connection closes immediately or only after a long timeout (e.g. 30 seconds).

Does the problem disappear if the content is loaded while Fiddler isn't running?

To troubleshoot this at the lowest level, you could use Wireshark or Microsoft Network Monitor to capture a .PCAP file of the scenario and then we could see at a packet level which is/isn't coming from the server.

Regards,
Eric Lawrence
Telerik
 

See What's Next in App Development. Register for TelerikNEXT.

 
Anuj
Top achievements
Rank 1
commented on 28 Apr 2015, 10:43 PM

Thanks Eric for your reply. The problem disappears when Fiddler isn't running.

The IP address on both affected and unaffected machines is the same I am pasting the properties below. I will try the packet level comparison.

Affected machine

 SESSION STATE: Aborted.
Response Entity Size: 512 bytes.

== FLAGS ==================
BitFlags: [ResponseGeneratedByFiddler] 0x100
X-ABORTED-WHEN: Done
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 47470
X-EGRESSPORT: 47471
X-FAILSESSION-WHEN: ReadingResponse
X-HOSTIP: 213.95.121.28
X-PROCESSINFO: iexplore:23192

== TIMING INFO ============
ClientConnected: 13:54:00.380
ClientBeginRequest: 13:54:00.395
GotRequestHeaders: 13:54:00.395
ClientDoneRequest: 13:54:00.395
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 5ms
HTTPS Handshake: 0ms
ServerConnected: 13:54:00.401
FiddlerBeginRequest: 13:54:00.401
ServerGotRequest: 13:54:00.401
ServerBeginResponse: 13:54:01.067
GotResponseHeaders: 00:00:00.000
ServerDoneResponse: 13:54:01.067
ClientBeginResponse: 13:54:01.069
ClientDoneResponse: 13:54:01.069

Overall Elapsed: 0:00:00.674

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.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.

Unaffected machine

SESSION STATE: Done.
Response Entity Size: 30788 bytes.

== FLAGS ==================
BitFlags: [None] 0x0
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 51171
X-EGRESSPORT: 51179
X-HOSTIP: 213.95.121.28
X-PROCESSINFO: iexplore:3912
X-RESPONSEBODYTRANSFERLENGTH: 30808

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

This traffic was captured on Monday, April 27, 2015.

ClientConnected: 09:45:17.057
ClientBeginRequest: 09:45:31.129
GotRequestHeaders: 09:45:31.129
ClientDoneRequest: 09:45:31.129
Determine Gateway: 0ms
DNS Lookup: 3ms
TCP/IP Connect: 3ms
HTTPS Handshake: 0ms
ServerConnected: 09:45:31.145
FiddlerBeginRequest: 09:45:31.145
ServerGotRequest: 09:45:31.145
ServerBeginResponse: 09:45:31.472
GotResponseHeaders: 09:45:31.472
ServerDoneResponse: 09:45:31.800
ClientBeginResponse: 09:45:31.800
ClientDoneResponse: 09:45:31.800

Overall Elapsed: 0:00:00.670

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.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.

 

Anuj
Top achievements
Rank 1
commented on 29 Apr 2015, 02:00 AM

Hi Eric,

 I have captured the wireshark trace from the affected machine and it looks like the client is closing the connection by sending a RST packet to the server. This occurs only when fiddler is running. Please let me know the best way to share to trace.

Thanks,

Anuj

Eric Lawrence
Telerik team
commented on 30 Apr 2015, 03:17 PM

Hi, Anuj--

You can send me the file using the Help > Send Feedback command in Fiddler.

Thanks for your help!

Eric Lawrence
Telerik
 

See What's Next in App Development. Register for TelerikNEXT.

 
swap
Top achievements
Rank 1
commented on 23 Nov 2015, 05:50 AM

do we have further comments to this or similar thread? we are facing the similar issues. 
Eric Lawrence
Telerik team
commented on 23 Nov 2015, 03:57 PM

Hi, swap-- It's not really clear what you're asking, or how anyone can help you without more information.

If your question is "What does this message mean", the answer is in the first response: The error message you're showing below means exactly what it says-- The server accepted the request and then closed the connection without sending any bytes back. It's possible that this happened because the server didn't like some aspect of the request (e.g. the IP address from which the request was sent, the User-Agent header on the request, etc) or because the server is buggy, or the network connection failed, etc. A properly functioning server *should* return an error message in the event that it deliberately does not want to provide a resource, but not all do so.

Regards,
Eric Lawrence
Telerik
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Janus
Top achievements
Rank 1
commented on 14 Apr 2016, 02:23 PM

I hope the Eric was having a bad day, such a problem should in no way be addressed like that.

I'm facing the same problem, and experience the same as 

"Hi Eric,
 I have captured the wireshark trace from the affected machine and it looks like the client is closing the connection by sending a RST packet to the server. This occurs only when fiddler is running. Please let me know the best way to share to trace."

I'm developing in C# and this suddenly came out of nowhere. 

In the good old days Eric when you were developing Fiddler you would have handled the problem and investigated it better.

Tsviatko Yovtchev
Telerik team
commented on 19 Apr 2016, 12:51 PM

Hi Janus,

Eric is not developing Fiddler any more. Telerik took over after he moved to Google in the beginning of 2016. 

Rather unfortunately, that does not invalidate all his thoughts on this issue. It is quite possible that the server side does something weird.

Could you elaborate some more on your scenario? Do you have any control over the server? Have you tried connecting to the server via some other proxy? Have you tried running the client/Fiddler setup on a different network?

Regards,
Tsviatko Yovtchev
Telerik
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
0
Jarred
Top achievements
Rank 1
answered on 22 Apr 2016, 12:46 AM
Setting connection:keep-alive in the header solved it for me
Tags
FiddlerCore
Asked by
Anuj
Top achievements
Rank 1
Answers by
Eric Lawrence
Telerik team
Jarred
Top achievements
Rank 1
Share this question
or