I have a web application running on .Net Core 2.2 and so far it has been deployed on various servers on IIS
screenshot of web.config
The cookies created on all the servers so far are around 2.7kb
screenshot of usual behavior - localhost
screenshot of usual behavior - public domain with htps
When deployed on a particular server that cookie becomes too large and is chunked. Causing problems overall screenshot of chunked cookie
Does anyone know what is causing this?
Related
We are trying to migrate our REST Web API from being hosted as a Windows .NET Core 3.1 stacked web app to a containerized web app on Linux on Azure.
So far we have managed to push the image to the Azure Container Registry where it's being automatically picked up and successfully deployed to an App Service. Unfortunately, the app does not properly work yet. When trying to fetch some configuration data from a (anonymous) end-point from our API (GET https://foo.azurewebsites.net/api/configuration), instead of returning the data - as it used to do - I get a 301 (Moved Permanently) status code that points exactly to itself: location: https://foo.azurewebsites.net/api/configuration which leads to redirection loop.
So far I have no idea why I'm getting a 301 and I'm glad for any hints.
Points of interest:
Docker: the base for the image is: mcr.microsoft.com/dotnet/core/aspnet:3.1
Azure: Authentication / Authorization is switched off
Azure: no Front Doors are installed
The app is correctly serving the Swagger UI.
The Docker image works fine locally.
Here's how I solved the problem: it turned out that the cause for the permanent redirect loop was a conjunction of how the proxy works in the Azure deployment (thanks to Jason Pan for pointing me in that direction) and the following code that we had in our Startup:
services.AddControllersWithViews()
.AddMvcOptions(o =>
{
...
o.Filters.Add(new RequireHttpsAttribute { Permanent = true }); // REMOVE THIS LINE
...
});
Once I removed RequireHttpsAttribute filter, the app started working as expected. And since I've configured the TLS/SSL settings to allow HTTPS only, I think it is safe to omit the filter.
UPDATE 2021-01-20
I've just figured out that there's a better way to do this that does not require to remove the RequireHttpsAttribute filter. The core of the problem is that Kestrel does not know that communication is happening over a secure channel as the reverse proxy is forwarding requests over http to Kestrel. So we need to enable the forwarding of headers. For .NET Core 2.x applications this meant to follow the steps explained in Configure ASP.NET Core to work with proxy servers and load balancers. Luckily, for ASP.NET Core 3.x applications there a much more simpler way (that unfortunately is not mentioned in the official docs yet but was part of the preview 6 announcement): simply set the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable to true. This can be done the usual way in the Azure portal under Confguration > Application settings:
I have followed the instructions here and here to setup SignalR in a ASP.NET Core web app. Then replicated the same code in a Service Fabric ASP.NET Core service only to find that the 100% working code when hosted outside of service fabric did not work when hosted on Service Fabric. When I open the html client included in both of these samples and turn on developer tools in the browser I see what appears to be the WebSocket handshake failing with HTTP 410 GONE errors.
In the Service Fabric documentation for ASP.NET CORE I found that the ServiceFabric Middleware can return HTTP 410 GONE if the identifier that validates each request does not match. But I guess I don't understand the inner workings of SignalR to know how to properly configure Service Fabric to unblock this.
I am running on a local single node cluster so I figured that I wouldn't have any issues until I needed to do multi-node cluster deployment, at which point I would need to figure out the SignalR backplane I'm going to use.
Any idea what would cause this to be?
I needed to disable Service Fabric Integration in the WebHost Builder. Simply replacing this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
with this:
.UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
allowed it to start working.
I've just upgraded an ASP.NET Core 1.1 web application to 2.0 and tested without issue locally. However, when the site is deployed to Azure a POST request that worked locally results in a 404 (I guess this could be the same for all POST requests, but I'm unable to log-in due to the issue).
Any ideas why this might fail to be working when deployed to Azure but working perfectly when run through IIS Express locally?
I deleted the original deployment slot on Azure and re-created as initially deploying over the slot mixed old 1.1 DLL's with the newer 2.0 DLL's and prevented the site working at all.
Seems I was caught out by poor handling of errors by my web application. I'd assumed that app.UseExceptionHandler("/Error") (I default my HomeController to not require the leading "Home" for /Home/Error) in Startup.cs would redirect to an error page, but for me it is not.
My underlying issue was a database connection error that caused the POST controller method to fail. I was caught out by the response returning a 404 rather than an error status.
I will need to investigate how error handling works in more detail for ASP.NET Core it seems.
I am using Asp.net MVC 4 Web Api project. MY application uses mvc to implement a web site. It makes http requests to the web api to implement server functionality.
Regular page requests to controllers work fine and it is able to display web pages. The application is able to make get and post requests to the api. But when it tries to to put or delete web requests it gets
"Failed to load resource: the server responded with a status of 501 (Not Implemented) "
The application is hosted on iis 6.
The application works when running a local cassani server instance and is able to make put and delete requests, but as soon as the application is executed from iis it doesn't work as expected.
I tried all the suggestions from the comment above and none of them worked.
I had to add the ASP.NET 4.0 dll to the Wildcard mappings in the Configuration area on the Home Directory tab. That worked for me. Remember to uncheck the "Verify file exists" checkbox.
EDIT: I posted a blog on the exact process to make this happen here: http://www.proworks.com/blog/2012/11/14/how-to-fix-aspnet-mvc-web-api-http-put-and-delete-requests-failing/
We are in the process of developing a .NET based IIS hosted web application as part of a re-platforming project. The original web app is on a Netscape server, in the process of migration we need to point the dns to the IIS server so that the requests are responded by IIS. at the same time we would still need the Netscape server so as to redirect the users from the IIS web app for the regions of the web site which the new application doesn't process (yet).
The old application is frame based, so we plan on using IFrames in the content area (of a master page in web client software factory) and use a URL rewrite engine to render pages from the old system in the iframe.
We also need to point the DNS entry which currently points to the Netscape server to IIS.
Are there and best practices for the above activities?
Maybe this link can help: Migrating a Web Server to IIS: Basic Steps
It discussed the steps you can take to get ready for Internet Information Services (IIS). In this article, the author takes a "nuts and bolts" approach to migrating an individual Web server.
You'll find detailed information about migrating configuration settings and content to a server running IIS 5.0 from another type of Web server, such as Apache HTTP Server or Netscape Enterprise Server.