ReadResponse() failed: The server did not return a response for this request.
If you have found this Blog entry most likely you are seeing this response in Fiddler. It is accompanied by an HTTP status code of 504. ReadResponse() failed: The server did not return a response for this request is not very helpful and in fact fairly useless in debugging the problem, well short of looking up the exact phrase on Bing or Google to find this blog :).
I hit this error when trying to return an extremely large set of records via a WCF service today. In fact back at the New York City Code Camp I was asked if WCF could serialize a large dataset into JSON and I started playing at the time. I had sort of forgot about this over the past few months.
Diagnosing the problem involved turning on WCF Tracing and verifying my suspicion that I had hit a default limit. Well the WCF DataContractSerializer has a limit of 65536 object in the object graph. So I did the match on my demo data I was using to work through this issue and yes, I was over that limit in the number of objects. I had a 13 property object and crossing the 5041 record limit caused this issue to surface.
Now back to the ReadResponse() failed issue when using Fiddler. This is my suspicion at this point, so take it for what it’s worth. Based on things I read Fiddler creates this error message in response to a network error, hence the HTTP 504 status code, which is NOT an IIS generated code. It is actually a proxy generated status code and since Fiddler is a proxy this is why you get a 504.
My deduction is the large record set pushes some sort of limit on the network packets and an end of file is missing. Hence Fiddler cannot complete processing of the file stream coming in and promptly throws the proxy error.
I guess how you limit your set of data is up to you. Two strategies that I like are checking the potential size and throwing a ThisIsNotGoingToHappenException to the user so you can let them know they need to do something more to limit the results more. The next is limiting the results to say 500 or 1000 or some other manageable arbitrary size of your choosing and letting the user know there might be more. Either way I think its a good idea to let the user know there is more available, just be more specific. Of course you will have to give them a way to reduce the set.
If you are not having an issue with large responses being sent from the server and you still get the ReadResponse failed error from Fiddler, there is most likely something that is causing a corrupt stream to be sent from the server to the client, Fiddler in this case.