Asp.net MVC Web Api Http put and delete requests failing - iis-6

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/

Related

Azure web app deployed as docker container endless 301 loop

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:

ssl access in web API ASP.Net Core 2

I want to force the access to my web API with SSL
In Visual Studio I see this
The to force the calls to use https I have this
.UseRewriter(new RewriteOptions().AddRedirectToHttps(301,44329))
But when I make this call for example: http://localhost:5001/api/proyectos that until now worked fine. Now this call is translated to https://localhost:44329/api/proyectos and the page is nod loaded.
Any idea please?

Web Api hosted on another port on IIS is not accessible

I have two separate projects
MVC Web App
MVC Web API
I have published both on my IIS 7.5
My Web App is hosted on 7172 port
and Web API is hosted on 7171 port
Strangely iam not able to call jquery.ajax() from my web app (7172) to web api (7171) port. It gives me 405 Method not found error code.
But if i write the same jquery.ajax() in my web api project (7171) and call web api method then it work fine and returns data.
I want to call web api from my web app.
Any suggestion would be appreciated.
Thanks in advance.
This has to do with the Same Origin Policy. By default, you can't execute an AJAX call to another domain (both on name, port and protocol).
If you want to enable this you should use Cross-origin resource sharing (CORS). CORS can be used with Web API by installing a (prerelase) NuGet package: Microsoft ASP.NET Web API Cross-Origin Support
This package allows you to configure which domains can call your service. You can find a walk trough here Enabling Cross-Origin Requests in ASP.NET Web API. In essence it comes down to adding attributes to your controllers like this:
[EnableCors(origins: "http://myclient.azurewebsites.net", headers: "*", methods: "*")]
You're running into the same-origin/cross-domain security policy. The port used is part of the origin calculation. A bit of Javascript loaded from (say) localhost:80 cannot make an AJAX request to localhost:8080, because the port numbers don't match. The 405 error you're getting is almost certainly coming from your Web App, not the API - check the server logs for the app, and you'll see the ajax hit in there.

Returning a 401 Unauthorized from WCF Web API in an MVC 3 App

I'm using the WCF Web API (the latest version, which I think is 0.5, obtained from the VS2010 Ultimate integrated package dependency GUI).
I've got a simple API class exposed and in each method I'm making a call that performs authorization against the user. When the user is unauthorized, I throw an HttpResponseException with the 401/unauthorized code.
This works, and you can see that at some point in the Http Handler chain, the 401 was trapped. The problem is that the site in which the API resides contains ASP.NET Forms authentication... and so when it sees the 401, it tries to forward my client request to the logon page.
How do I disable this behavior for a particular sub-directory within my site? I've tried setting a location of "api" always allowing users... but I still throw a 401 which still causes ASP.NET to try and redirect me to the logon page.
I'm sure I'm just missing a simple configuration setting that tells forms auth to ignore requests for the /api/* directories, but I can't find any information on it.
I have described the problem and it's solution here (with Preview4): Basic Authentication with WCF Web API hosted in IIS / Getting a 404 - Disable Forms Authentication Redirection

MVC Mini Profiler on IIS 6

Has anyone been able to get the MVC mini profiler working on IIS 6? I've set up the profiler in my application and it works perfectly in Visual Studio, IIS Express and IIS 7.5 but when I put the exact same application onto IIS 6 it won't work.
The problem seems to be around loading /mini-profiler-includes.js, I just get a 404 response. I've checked the route table and the correct routes have been registered by the profiler but apart from that I'm not sure what else to try.
On IIS 7, ASP.NET by default runs in integrated mode so the ASP.NET runtime will handle all requests, however on IIS 6 ASP.NET only handles extensions explicitly listed in the mappings section.
When the request comes in for /mini-profiler-includes.js IIS sees the .js and tries to serve the static file but as the file is "generated" by ASP.NET the handler never gets hit and a 404 error is returned.
In order to fix this you need to add a wildcard mapping to IIS so all requests get handed to ASP.NET. This blog post has a good walkthrough of the process.