strange behavior of WebAPI - responds differently when called from different machines

Question

I have a WebAPI service deployed on a server. There is also an MVC app for testing the API. One such tester runs on my dev machine and another copy (same version) runs on the server where API resides.

The MVC tester app supports calling API directly and also through a built-in 'proxy' (http handler) to bypass the "Access-Control-Allow-Origin" errors. So for example if I run the tester app on my dev machine and I want to receive data from the server, I must use the proxy. This setup works nicely and all of the calls are going through and data is passed properly.

Problem occurs when I don't provide enough inputs (for testing purposes) and API generates a "400 Bad request" error. It only happens when I make a call from my dev machine to remote machine and works fine if I make the same call on the server.

I tested with Postman on the remote server:

post directly to API: POST to 177.77.77.77/v1/feature {JSON payload}

the response I get back contains proper headers, a body with a JSON object describing the error. Same thing happens when I send the same exact command but through server's proxy:

post through proxy: POST to 177.77.77.77/proxy/feature {JSON payload}

both results are identical and this is the expected behavior, which I think allows to make a conclusion that proxy is working and API is working.

When I go back to my dev machine and try the same calls, my result for posting directly to API is the same as above but if I use the server's proxy something else happens. Here's output from Fiddler for the working case (from dev machine directly to API):

POST http://177.77.77.77/v1/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

{payload}

response:

HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:48:52 GMT
Content-Length: 139

{"code":"INVALID_REQUEST","message":"proper error message"}

this is the correct behavior with expected message body (JSON) and correct content-lenght. If I make a request to the server's proxy, my request becomes:

POST 177.77.77.77/proxy/feature HTTP/1.1
Host: 177.77.77.77
Connection: keep-alive
Content-Length: 514
User-Agent: Mozilla/5.0 xx..
Cache-Control: no-cache
Origin: chrome-extension://xx-postman-xx
Authorization: Basic pwd=
Content-Type: application/json
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: appSettings=xx

{payload}

then the response I get is:

HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 30 Mar 2015 15:51:37 GMT
Content-Length: 11

Bad Request

the body/payload of the response is lost or replaced by status, content-type changed from JSON to text/html and cache-control became private.

The cookie in the non-working case plays no role. I tried removing it and result is still wrong.

Why do you think this is happening? How can I troubleshoot this and find what portion of code (or maybe IIS setting?) is responsible for sending a different response for what seems to be same requests? After all everything works fine when I run only on dev or only on remote. Could this be some permission issue or something in IIS on the server?

I tried remote-debugging of the proxy code where I would step through the code while sending Post commands (with the same payload) through Postman. In one scenario I ran Postman on the server and made a request to server's proxy and in another scenario I ran Postman on dev and also made requests to server's proxy. In VS I can see that I'm going through the same path in code for both scenarios and that API's response is the same.

Thanks for reading and any attempts to help will be greatly appreciated!

Answer 1

added this to web.config:

<system.webServer>
    <httpErrors existingResponse="PassThrough"></httpErrors>
</system.webServer>

found the solution here: In IIS7.5 what module removes the body of a 400 Bad Request