We're migrating a .NET web application from Windows Server 2012 running IIS 8.5 to Windows Server 2019 running IIS 10.0.
We have some code which sends a PATCH request from one bounded context into an API in another bounded context. The response to this request is 204 (No Content).
The request is sent through a common method which attempts to parse the body for successful responses (i.e., 2xx codes).
if (response.IsSuccessStatusCode)
{
var responseContent = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
// ...
}
Maybe this needs changed but that's not what puzzles me.
When responded from Windows Server 2012 / IIS 8.5 the parsing of a 204 (No Content) response using the above code caused no problems.
When responded from Windows Server 2019 / IIS 10.0 the parsing of the same response using the same code causes an exception.
System.IO.IOException: The response ended prematurely.
Why?
The code is running on the same version of .NET Framework on both servers.
Does IIS handle 204 (No Content) responses differently?
Related
My python app (evernote-sdk-python3) worked fine until June, 3rd. Suddenly it breaks e.g. when I call "client.get_user_store()" or "client.get_note_store()". All calls to "evernote.edam.userstore.UserStore.Client" respond with HTTP status 400 (The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)). I tried it in a sandbox and on the production server and I renewed the auth token. Nothing helped. Something on evernote's side must have changed. My app worked perfectly before.
the Evernote python3 SDK just got a patch, please grab the latest and try again
So let's start with little info in the beginning.
I have nodejs server side app and client app on angular. I send only get requsts to server app just to read data from database. When i started my apps on local machine they were working pretty well. But when i deployed them to server i got such error : (below in screen)
screen with error from angular
So, i added cors support in server app and add Allow Headers. code in nodejs
But it doesn`t help. When i post "GET" request i get my allow headers in response header and my data that i need in body.
screen with response headers in postman
screen with response body in postman
Server - apache. One interesting thing that server app works good with http protocol and when i am using htttps get this errror error with https
But angular works on https.
i am facing an issue with azure proxy call.
Created a azure function app.
Created a basic get function and sending response body in json format back.
response body example{url: "https://www.google.com"}
If i configure direct function endpoint in one of my company application everything working fine able launch response url coming from azure function call.
I created proxy for the same get function and configured proxy end point in my application.Now application is failing to launch response url.(but back end same function is hitting and logs created no error in logs and ended with status 200)
Unfortunately i don't have control on application code to verify what exact cause in response.
I verified azure function call and proxy call from postman both are giving same response body. I don't know why it is failing in my application
i didn't understand.
One more point i verified response headers in postman in both cases
For function app end point call response headers:
content-type →application/json; charset=utf-8
date →Wed, 09 Jan 2019 12:39:23 GMT
server →Microsoft-IIS/10.0
transfer-encoding →chunked
x-powered-by →ASP.NET
For proxy endpoint call response headers:
content-encoding →gzip
content-length →208
content-type →application/json; charset=utf-8
date →Wed, 09 Jan 2019 12:41:16 GMT
server →Microsoft-IIS/10.0
vary →Accept-Encoding
x-powered-by →ASP.NET, ASP.NET
is gzip encoding creating problem in proxy call. How to disable it in azure proxy.
my application should able to launch even if i use proxy end point.
So I have an application which needs to send data to the API which is created by our team leader using NodeJS with Express.js.
On my end I have laravel application which using VueJS for the UI. Inside the Vue JS component. I am using axios to request to the API.
axios.post('https://clearkey-api.mybluemix.net/sendcampaign', request)
.then(function(response) {
//console.log(response);
})
However, it returns 204 which means according to this https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.
204 No Content
The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.
If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent's active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
Then next it returns 500 Internal Server Error. So in my opinion it returns this error because there is no content to be returned from the server?
Can you tell me other possible problems why it return that response?
Check if the "HTTP method" of the 204 is OPTIONS and if the method of the 500 is POST.
If both are like that, then you are seeing first a CORS pre-flight request (the OPTIONS that returns 204) and then the actual request (the POST that returns 500).
The CORS pre-flight request is a special HTTP message your browser sends to the server when the webpage and the backend are hosted at different addresses. For example, if your website is hosted at http://localhost but the backend you are trying to access is hosted at https://clearkey-api.mybluemix.net.
The reason of the 204 just means your backend endpoint is correctly setup to handle requests for /sendcampaign (you can ignore it). The reason of the 500 is because of some exception in the implementation of the function that handles that endpoint.
I have created a REST web service using Web API 2.2 on a Windows Server 2008 R2 box running IIS 7.5. The problem that I'm having is that the web service is returning a compressed response (Content-Encoding: gzip) when I make the request through the Google Chrome Postman application. But when I make the same request using the .NET 4.5.1 HttpClient, the server does not return a compressed response (the Content-Encoding header is blank). Here is my C# code:
var handler = new HttpClientHandler();
handler.UseProxy = false;
handler.AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate;
handler.Credentials = CredentialCache.DefaultNetworkCredentials;
var client = new HttpClient(handler);
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
client.DefaultRequestHeaders.AcceptCharset.Add(new StringWithQualityHeaderValue("utf-8"));
client.DefaultRequestHeaders.AcceptLanguage.Add(new StringWithQualityHeaderValue("en-US"));
client.DefaultRequestHeaders.CacheControl = new CacheControlHeaderValue { NoCache = true };
client.DefaultRequestHeaders.Connection.Add("keep-alive");
var response = await client.GetAsync("https://localhost/mywebsite");
Note: I'm using an SSL connection. I can confirm that the Web API web service is receiving the Accept-Encoding: gzip header from both the Postman application request and the HttpClient request. In fact, the request headers are exactly the same for both, except that the Connection: keep-alive header seems to be stripped from the HttpClient request. Does anyone have any idea why the web service won't serve a compressed response to the HttpClient?
So, I monitored the HTTP traffic using Fiddler and lo and behold the server response was in fact compressed when using the HttpClient (the number bytes received by Postman was the same as the number of bytes received by HttpClient) and had sent the corresponding Content-Encoding: gzip header! I guess that the HttpClient is trying to be smart by removing the Content-Encoding: gzip header when it is in automatic decompression mode. Is this documented anywhere?
you fiddler decode auto,you can disable fiddler auto decode