使用HttpResponseMessage时Web API无响应，Postman/Fiddler无法获取返回结果

Let’s break down why you’re seeing "Could not get any response" in Postman/Fiddler even though your code runs fine in VS 2017’s IIS Express. Here are the most likely culprits and actionable fixes:

1. Stop Manually Instantiating HttpRequestMessage and HttpConfiguration #

Your code includes these two problematic lines that break the Web API framework context:

Request = new HttpRequestMessage(); 
Configuration = new HttpConfiguration();

The Request property in a Web API controller is automatically populated by the framework with the incoming request’s context. When you overwrite it with a new, empty instance, any response you generate won’t be tied to the actual incoming request—this leads to the server not sending a valid response back to Postman/Fiddler.

Fix: Delete both lines entirely. Use the controller’s built-in Request property instead.

2. Remove Duplicate Response Content Setup #

Your error response code is redundant and can cause stream/encoding conflicts:

var response = Request.CreateResponse(HttpStatusCode.InternalServerError, JsonFunctions.BuildErrorResponse("", Constants.ValidationMessage.MEMBER_NOT_IN_LDAP));
response.Content = new StringContent(JsonFunctions.BuildErrorResponse("", Constants.ValidationMessage.MEMBER_NOT_IN_LDAP));
response.Content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/json");

When you call Request.CreateResponse with an object, Web API automatically serializes that object to JSON, sets the Content-Type header to application/json, and creates the appropriate HttpContent for you. Overwriting the Content property afterward is unnecessary and can break how the response stream is handled.

Fix: Simplify this to clean, maintainable code:

var errorPayload = JsonFunctions.BuildErrorResponse("", Constants.ValidationMessage.MEMBER_NOT_IN_LDAP);
var response = Request.CreateResponse(HttpStatusCode.InternalServerError, errorPayload);
// No need to manually set Content or Content-Type—Web API handles this automatically
return response;

3. Fix Stream Parameter Handling #

Your method accepts a Stream as input, which is prone to silent failures if not handled correctly:

• Ensure that in JsonFunctions.GetServiceRequestParameters, you reset the stream’s position to the start before reading:

  inputServiceRequestParameters.Position = 0;
  // Then read the stream content
  

  If the stream was partially read by framework middleware before reaching your method, you’ll get empty or invalid data—this might not throw an exception, but it can break downstream logic and prevent a valid response from being sent.
• Alternatively, replace the Stream parameter with a strong type (e.g., a custom ServiceRequestParameters class). Web API will automatically deserialize the JSON request body for you, eliminating stream-handling pitfalls entirely.

4. Check for Unfinished Code Paths #

You only shared the code for when contactId == null, but what happens when contactId is valid? If the rest of your method doesn’t return an HttpResponseMessage, the request will hang indefinitely (until timeout), causing Postman/Fiddler to report a connection error.

Fix: Double-check that every code path in your method returns a valid HttpResponseMessage. Add simple logging (e.g., System.Diagnostics.Trace.WriteLine("Returning error response")) at key points to confirm which paths are executing.

5. Resolve Postman/IIS Express Network Blocks #

Even if VS tests work, Postman might hit network-related issues:

• Disable Postman’s system proxy: Go to Settings > Proxy and uncheck "Use system proxy". System proxies often interfere with localhost requests.
• Try using http://127.0.0.1:12345/Url/RequestUrl instead of localhost—some DNS or proxy setups treat localhost differently.
• Verify IIS Express bindings: Open your project’s .vs/config/applicationhost.config file, find your site’s bindings, and ensure they include http://localhost:12345 (no external IPs unless you’ve explicitly configured access).

6. Debug with Logging & Fiddler #

Since Fiddler shows ReadResponse() failed, this means the server closed the connection without sending a response. Add detailed logging to track execution:

• Use System.Diagnostics.Trace or a logging library (like Serilog) to log messages at the start of the method, after key steps, and right before returning responses.
• Enable Web API exception logging to catch any silent exceptions that might crash the request without triggering your try/catch block.

内容的提问来源于stack exchange，提问作者kerc