I have an app service that is working as expected in that I can get to pages, log in, and perform a search.
In the event of errors I have the below code in place in the MVC Controller (not an API endpoint)
{
_log.Error("Customer Search Failed", ex);
Response.StatusCode = 500;
return new JsonResult()
{
Data = new { Success = false, Error = "An error occured.", Amount = 0 },
JsonRequestBehavior = JsonRequestBehavior.AllowGet,
ContentEncoding = System.Text.Encoding.UTF8
};
}
Locally, I get the following response along with an HTTP Status Code of 500:
{"Success":false,"Error":"An error occured.","Amount":0}
In Azure, though, I get this response:
The page cannot be displayed because an internal server error has occurred.
I have written a test app to reproduce this in my own Azure environment so that there wouldn't be anything company Azure Resources that could cause this and I got the same behavior. No application gateways, VNets, anything like that. The app service itself is effectively seeing the 500 HTTP Status Code and then sending its own response vs what I want to send.
Does anyone know why this is happening and/or how to prevent this from happening?
The problem was that Azure must set up standard responses for non-200 HTTP Status Codes. This overrode what my Controllers were returning.
I had to explicitly remove the 500 httpHeader via the web.config in order to see the JSON response I was expecting.
<httpErrors errorMode="Detailed">
<remove statusCode="500" />
</httpErrors>
Related
So we have a simple .net core 5.0 service that only serves some simple pages with mvc. We are starting to get 400 Errors (details below) on some of the requests. Our frontend is embedded in an iframe which forces us to use our own domain for our api-calls. The 400 errors disappears when we use the azure internal-urls. (*.azurewebsites.net instead of *.ourdomain.net). When I get to the "diagnose and solve problems" -> "availability and performance" -> HTTP 4XX ERRORS i can se below errors. Any ideas on what can cause this error?
Bad Request. The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications.
So, the biggest problem above is that we do not get the correct errormessage. After a lot of experimentation we activated the ConnectionLogging for Kestrel.
WebHost.CreateDefaultBuilder(args)
.UseKestrel(options =>
{
options.ConfigureEndpointDefaults(listenOptions =>
{
listenOptions.UseConnectionLogging();
});
})
And after that we found some more intressting logs. One that said:
Connection id "0HMFSA73IA4LS" bad request data: "Malformed request: invalid headers."
Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.
After some more investigation we could diff a succesful request from a failing request. And the problem was related to the certificate of *.ourdomain.se. In a part of the certificate we hade a string thats named "Stockholms län" in the cases where it failed the string decoded to l�n and when it succeeded the string decoded to l%C3%A4n. We are now investigating if this is a load balancer problem. But this app is running hostingmodel outofprocess. By changing this to inprocess and wrap our Kestrel in IIS the errors disapears.
I am getting HTTP 400- Header too long error, I have tried most of solution over internet, but none of them seemed to be working (solutions are like adding reg entries, etc).
I have a sample web application which is calling a web api on my system, but I am getting below error in HTTPERR log file:
2019-11-16 16:58:59 ::1%0 1213 ::1%0 80 HTTP/1.1 GET
/WebApplication2/api/values - 400 - RequestLength -
Here is my code which is calling the web API:
HttpWebRequest GETRequest = (HttpWebRequest)WebRequest.Create(URL);
GETRequest.Method = "GET";
GETRequest.ContentType = "application/json";
GETRequest.Headers.Add("Authorization", "<Something Big value>");
WebResponse GETResponse = await GETRequest.GetResponseAsync();
It is recommended to capture ETL log via
https://blogs.msdn.microsoft.com/wndp/2007/01/18/event-tracing-in-http-sys-part-1-capturing-a-trace/
Then you could use network monitor to analyze both request payload and etl log.
It will help you find the root cause.
Besides, can you find the 400 error in IIS log? Now that the 400 error appear in httperr log. It looks like http.sys blocked the request before it reach IIS server.
If you can find the 400 error in IIS , then you could try to modify the limitation in system.web/httpRuntime and request filter.
If the 400 error only can be found in httperr log. Then you may have to try to make some change in http.sys registry.
https://support.microsoft.com/en-us/help/820129/http-sys-registry-settings-for-windows
Please remember to reboot server to activate these registry!
I have an ASP.Net Core 2 web api project.
I have added the following to the Configure method in my Startup.cs file
app.UseExceptionHandler();
I noticed in my Postman tests that I was getting an "Unable to get response" result.
Server-side logging shows that the error has to do with Tables being missing from my Database. Which is fine, I can resolve that. But my question is why would the server not be returning a 500 Internal Server Error? Why is it dying, and returning no response at all to Postman?
So, in my Controller, I purposely throw an Exception to test the handler, and call the URL from Postman, and indeed, I get back a 500 Internal server error response, as expected.
Why are the "deeper down" errors being thrown from EFCore not being handled by the ExceptionHandler middleware, and crashing my app? Am I missing something?
In your startup.cs, move the UseMvc() tag to the bottom of the pipeline i.e.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
...
app.UseExceptionHandler();
app.UseMvcWithDefaultRoute();
}
In my case, the request pipeline faulted on startup when the route launched by the browser did not exist. In that scenario, my app.UseExceptionHandler() before the app.UseMvc() was not executed.
I have a strange problem. I have a .NET Core App which works fine on local machine and passes unit tests.
Inside the app it basically calls our platform web service:
using( WebClient client = new WebClient() )
{
NetworkCredential creds = new NetworkCredential(_userName, _password);
CredentialCache credCache = new CredentialCache();
credCache.Add(new System.Uri(_baseUrl), "Basic", creds);
client.Credentials = credCache;
var url = _baseUrl + "/api/v1/Pricing/Rates";
client.Headers.Add(HttpRequestHeader.ContentType, "application/json");
var request = JsonConvert.SerializeObject(data);
System.Console.Out.WriteLine(request);
var response = client.UploadString(url, request);
var responseObject = JObject.Parse(response);
var products = responseObject["PricingProducts"].Children();
var result = new Dictionary<string, double>();
foreach( var product in products )
{
result.Add(product.Value<string>("LoanProgramName"),
product.Value<double>("Rate"));
}
return result;
}
When I execute this on local machine using dotnet run, everything works fine. Unit tests work great too. The logs on the App Service don't tell me much except that I am getting a 403 from the platform web service.
ers.RatesController.Get (AlexaRates) with arguments ((null)) - ModelState is Valid
2018-02-24 06:37:44.418 +00:00 [Information] Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker: Executed action AlexaRates.Controllers.RatesController.Get (AlexaRates) in 201.3483ms
2018-02-24 06:37:44.447 +00:00 [Error] Microsoft.AspNetCore.Server.Kestrel: Connection id "0HLBRA4B41EO8", Request id "0HLBRA4B41EO8:00000002": An unhandled exception was thrown by the application.
System.Net.WebException: The remote server returned an error: (403) Forbidden.
at System.Net.HttpWebRequest.GetResponse()
at System.Net.WebClient.GetWebResponse(WebRequest request)
at System.Net.WebClient.DownloadBits(WebRequest request, Stream writeStream)
at System.Net.WebClient.UploadBits(WebRequest request, Stream readStream, Byte[] buffer, Int32 chunkSize, Byte[] header, Byte[] footer)
at System.Net.WebClient.UploadDataInternal(Uri address, String method, Byte[] data, WebRequest& request)
at System.Net.WebClient.UploadString(Uri address, String method, String data)
at Rates.RetrieveLatest() in D:\home\site\repository\AlexaRates\Rates.cs:line 50
at AlexaRates.Controllers.RatesController.Get() in D:\home\site\repository\AlexaRates\Controllers\RatesController.cs:line 22
at lambda_method(Closure , Object , Object[] )
at Microsoft.Exten
Has anyone experienced anything similar? I see a bunch 403 posts, but they are mostly about people calling a REST API hosted on the service not calling out.
The 403 forbidden error usually means the server understood the request but refuses to authorize it.
According to your error message, it seems that the error happens in Rates class and RatesController class, which you haven’t showed for us. You could set a break point to check the code in these classes by using remote debugging.
You say the project is working fine locally, but get error in Azure, so please make sure you have published all your projects and data sources to Azure. Check whether the ‘_baseUrl ‘ is from Azure. And make sure you have started the Azure App Service.
There may be other causes of 403 forbidden error. Such as page cache and logging in of cookie. You could refer to this article to learn how to fix the 403 Forbidden Error.
Cause of 403 Forbidden Errors
403 errors are almost always caused by issues where you're trying to access something that you don't have access to.
My fix was that I realized that our infrastructure guys added a IP restriction on the azure app. That is why the app was bouncing back with a 403.
I removed the IP restrictions on the "Networking" -> "Access Restrictions" page.
After trying to add headers and doing various other things the end result was the same - I was getting a 403 error on calling out to a web service.
The solution was to convert from a Web App to a VM and deploy the application there using the old school setup. The application worked there.
I want to do something when/if an insert operation on Azure Table Storage fails. Assume that I want to return false from the below code when I receive an error. _table is of type CloudTable and the code below works.
public bool InsertEntity(TableEntity entity)
{
var insertOperation = TableOperation.Insert(entity);
var result = _table.Execute(insertOperation);
return (result.HttpStatusCode == (int)System.Net.HttpStatusCode.OK);
}
I get the result 203 when the operation succeeds. But there are other possible results like "200 OK".
How can I write a piece of code that will allow me to understand from the status code that something went wrong?
Using the .NET SDK, any situation that needs to be handled will throw an exception. i.e. Any status code that is not 2xx will cause an exception.
To handle situations where something went wrong, I don't have to manually check the status code of the result for every request. All I have to do is to write exception handling code. Like below:
try
{
var result = _table.Execute(insertOperation);
}
catch (Exception)
{
Log("Something went wrong in table operation.");
}
From this page:
REST API operations for Azure storage services return standard HTTP
status codes, as defined in the HTTP/1.1 Status Code Definitions.
So every successful operation against table service will return 2XX status code. To find out about the exact code returned, I would recommend checking out each operation on the REST API Documentation page. For example, Create Table operation returns 201 status code if the operation is successful.
Similarly, for errors in table service you will get error code in 400 range (that would mean you provided incorrect data e.g. 409 (Conflict) error if you're trying to create a table which already exists) or in 500 range (for example, table service is unavailable). You can find the list of all Table Service Error Codes here: https://msdn.microsoft.com/en-us/library/azure/dd179438.aspx.
Basically, any return in 2xx is "OK". In this example:
https://msdn.microsoft.com/en-us/library/system.net.httpstatuscode%28v=vs.110%29.aspx
203 Non-Authoritative Information:
Indicates that the returned metainformation is from a cached copy
instead of the
origin server and therefore may be incorrect.
This Azure white paper elaborates further:
http://go.microsoft.com/fwlink/?LinkId=153401
9.6.5 Error handling and reporting
The REST API is designed to look like a standard HTTP server interacting with existing HTTP clients
(e.g., browsers, HTTP client libraries, proxies, caches, and so on).
To ensure the HTTP clients handle errors properly, we map each Windows
Azure Table error to an HTTP status code.
HTTP status codes are less expressive than Windows Azure Table error
codes and contain less information about the error. Although the HTTP
status codes contain less information about the error, clients that
understand HTTP will usually handle the error correctly.
Therefore, when handling errors or reporting Windows Azure Table
errors to end users, use the Windows Azure Table error code along with
the HTTP status code as it contains more information about the error.
Additionally, when debugging your application, you should also consult
the human readable element of the XML error
response.
These links are also useful:
Microsoft Azure: Status and Error Codes
Clean way to catch errors from Azure Table (other than string match?)
If you are using Azure Storage SDK accessing Azure Table Storage, the SDK would throw a StorageException on the client side for unexpected Http Status Codes returned from the table storage service. To extract the actual HttpStatusCode you would need to wrap your code in a try {} catch(StorageException ex){} block. And then parse the actual exception object to extract the HttpStatusCode embedded in it.
Have a look at Azure Storage Exception parser I implemented in Nuget:
https://www.nuget.org/packages/AzureStorageExceptionParser/
This extracts HttpStatusCode and many other useful fields from Azure StorageExceptions. You can use the same library accross table, blob, queue clients etc. as they all follow the same StorageException pattern.
Note that there will be some exceptions thrown by the Azure Storage SDK that are not StorageExceptions, those are mostly client side request validation type of exceptions and naturally they do not contain any HttpStatusCode. (Hence you would need to have a catch for specifically StorageExceptions to extract HttpStatusCode s).
As a separate note, Azure Storage SDK has a fairly robust retry mechanism for failed requests. Below is the snippet from SDK source code where they decide if the failed response is retrieable or not.
https://github.com/Azure/azure-storage-net/blob/master/Lib/Common/RetryPolicies/ExponentialRetry.cs
if ((statusCode >= 300 && statusCode < 500 && statusCode != 408)
|| statusCode == 501 // Not Implemented
|| statusCode == 505 // Version Not Supported
|| lastException.Message == SR.BlobTypeMismatch)
{
return false; //aka. do not Retry if w are here otherwise Retry if within max retry count..
}