I have MVC Web API that have POST and PUT functions; POST function calls succeeded but PUT function call failed with:
internal server error;
Functions are identical "I use one function at a time and the other one will be commented; Just for testing purposes".
public HttpResponseMessage Put(string id)
{
HttpStatusCode statusCode = HttpStatusCode.OK;
return Request.CreateResponse<string>(statusCode, id);
}
public HttpResponseMessage Post(string id)
{
HttpStatusCode statusCode = HttpStatusCode.OK;
return Request.CreateResponse<string>(statusCode, id);
}
Edit: It works fine locally at my machine for both POST and PUT (Windows 8.1); but when i move it to another machine (Windows Server 2012 )only POST functions works.
Use POST to create resources when you do not know the resource identifier. With POST creates, it is best practice to return the status of “201 Created” and the location of the newly created resource, since its location was unknown at the time of submission. This allows the client to access the new resource later if they need to
Finally i found a solution for this issue, it seems that there is an issue in WebDav, in some cases it is not enough to remove it from your application Web.Config you should disable it from IIS by following steps from this article How to disable WEBDAV in IIS
I will update this answer when i found exactly what is the problem with WebDav that make removing it from application Web.Config not enough for windows 2012 but working fine in windows 8.1
I had the same problem. PUT and DELETE endpoints worked while I was debugging in visual studio, but not when I deployed to IIS.
I had already added this
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
in my web.config, so I wasn't thinking about the WebDav. Ebraheem's answer had me looking closer at the WebDav.
Ended up that the IIS Server had WebDav Publishing enabled in Features and Roles. So I removed it and now everything works as expected.
The remove <remove name="WebDAVModule" /> is not enough. What I found out is that you have to specifically remove it from handlers as well and also just to make sure the verbs are allowed you can set them in the security node. The following is what I set in my web.config which allowed the put and delete to work without setting anything in IIS.
<!-- After the <system.web> node -->
<system.webServer>
<handlers>
<!-- default handler settings here if any -->
<!-- Add the following to remove WebDAV handler -->
<remove name="WebDAV" />
</handlers>
<modules runAllManagedModulesForAllRequests="false">
<!-- Add the following to remove WebDAV module -->
<remove name="WebDAVModule" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
<security>
<!-- Add the following to specifically allow the GET,POST,DELETE and PUT verbs -->
<requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="DELETE" allowed="true" />
<add verb="PUT" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
Related
We have a Web API webservice site, built in .NET 4.5.2, that we're trying to move to .NET 5.0.
We ran into what seems to be a common issue - when we deploy the site to our staging environment, none of the PUT and DELETE methods work. When we test them using the generated Swagger UI, we get 500 errors.
Note - we do not see these errors running in IIS Express, through the VS2019 debugger.
We browse the web, of course, and find an answer:
How do you fix a 500 Server Error while running REST PUT or DELETE requests?
So we create a web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="WebDAV" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
</system.webServer>
</configuration>
And that causes different problems.
We get HTTP 500 errors when we try to run the site in IIS Express through the VS2019 debugger, and
Running the site modifies the web.config.
The web.config now looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<remove name="WebDAV" />
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<modules>
<remove name="WebDAVModule" />
</modules>
<aspNetCore stdoutLogEnabled="false" hostingModel="InProcess" />
</system.webServer>
</configuration>
Note the addition of aspNetCore.
So, here's the thing.
We need this to work both when deployed to IIS, and when run locally, and
We can't have source files that are partially generated, during the build. Our whole build-and-version-control system is built on the idea that there are files that contain code that developers write and there are files that are generated during the build. The former we save version control and the latter we do not. We can add web.config to our version control, but if we do we cannot have its contents changing during a build or run.
So, what do we do?
How do we get this to work when deployed in IIS and when run in IIS Express when debugging?
And how do we deal with the web.config being modified during a debug run?
These sort of issues seem to show up for a great many reasons, and I can't pretend to have found an answer to all of them.
In this particular case, the problem was that VS was inserting bad elements into the web.config.
Adding the <handlers/> and <modules/> elements to remove the WebDAV caused VS to insert an <aspNetCore/> element:
<aspNetCore stdoutLogEnabled="false" hostingModel="InProcess" />
And the element that was inserted lacked the required processPath= attribute.
<aspNetCore processPath="dotnet" stdoutLogEnabled="false" hostingModel="InProcess" />
It is better to turn off WebDAV Publishing.
To do that :
Open "Turn Windows Features on or off". Now inside Internet Information Services\World Wide Web Services\Common HTTP Features\WebDAV Publishing. Uncheck it and click OK.
I have a SinglaR app (empty web application without any global.asax and RouteConfig) which works well.
http://localhost:62673/signalr/hubs shows 'ASP.NET SignalR JavaScript Library v2.2.0' javascript and it is working (I use Winforms client, not the javascript one).
But when I deploy it to the webhosting (virtual directory), on the address http://myhosting.xxx/virtualdirectory/signalr/hubs I get error 404 instead.
I have this in my web.config:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true">
</modules>
</system.webServer>
What else am I missing?
Thanx
Ok, I found it after a whole day. This directive in web.config is needed:
<add key="owin:AutomaticAppStartup" value="true"/>
I have a SUPER simple Web API. It is openly non-secure and simply provides free data. I'd like to move it from my personal server to shared hosting (e.g.: GoDaddy), but I'm having issues.
There are a lot of similar questions relating to 404 status when attempting to access Attribute Routing Web API services on shared hosting solutions. But none of them have worked for me. This is my SUPER Simple current setup:
Create a new .Net Framework 4.5 EMPTY C# Web Application named YourApplicationName
Ensure all checkboxes and packages are NOT Checked
Add a New "Global.asax" object
Replace the entire contents of the C# with the following:
using System.Web.Http;
namespace YourApplicationName
{
public class Global : System.Web.HttpApplication
{
protected void Application_Start()
{
System.Web.Mvc.AreaRegistration.RegisterAllAreas();
GlobalConfiguration.Configure((HttpConfiguration config) => { config.MapHttpAttributeRoutes(); });
}
}
public class TestController : System.Web.Http.ApiController
{
[System.Web.Http.Route("api/Test")]
public string Get()
{
return "Test Info";
}
}
}
Replace the Web.config file with the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<customErrors mode="Off" />
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
</system.web>
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
</configuration>
Delete ALL References other than System and System.Web
PM> Install the following two packages:
Install-Package Microsoft.AspNet.Mvc
Install-Package Microsoft.AspNet.WebApi.WebHost
With that, I can run in Dev, publish to my personal IIS, run on my company's IIS Servers, or even publish to azure (http://suamereapi.azurewebsites.net/api/Test) and if I navigate to the route, I appropriately get back "Test Info".
But when I publish to my shared hosting, I receive a 404 status. Note that mvc controllers that return Views work just fine in the shared hosting, just not the ApiControllers.
Possible Issue 1 is that the IIS pipeline is not set up as Integrated on the hosted account. Of course I have checked that mine is set to Integrated.
Possible Issue 2: Moreso related to API's NOT using Attribute Routing, is that the Register Routes needs to come before the GlobalConfiguration. This is not applicable in a pure Attribute-Routing Web API setup.
Possible Issue 3: Some of the DLL's aren't in the shared hosting GAC, and also are not published from your local setup because they are not Copy Local. I have altered Copy-Local to multiple setups from none, to just what is required, to all references.
Possible Issue 4: Shared hosting messes with the configuration paths because of virtual directories for subdomains or what not. That is fixed by adding a rewrite to the Web.config as such:
rewrite>
<rules>
<rule name="Remove Virtual Directory">
<match url=".*" />
<action type="Rewrite" url="{R:0}" />
</rule>
</rules>
</rewrite>
Possible Issue 5: Some say to fix the issue you need to add runAllManagedModulesForAllRequests="true" and work with the httpHandlers to remove and manually add extension handlers, and UrlRoutingModules.
I have done all combinations of these workarounds, but I can't imagine what the true issue is. Please let me know what I might be missing, I've spent days on this.
I created a new ASP.net MVC application using Visual Studio 2013 Update 4 and checked the box to use Application Insights. When I try and run the application (with or without debugging) the site never loads. When I debug it I noticed that it is getting stuck in Global.asax.cs on the line:
AreaRegistration.RegisterAllAreas();
I have taken a look at the answers on a few other questions including this one:
AreaRegistration.RegisterAllAreas() is not Registering Rules For Area
This did not solve my issue. I have deleted all of the content in the folders in this answer and restarted visual studio, restarted my PC and no matter what I do this method just hangs forever. It doesn't appear to just be slow, because I have waited for over 5 minutes and it still hasn't finished. Has anyone else run into this scenario and how can I fix it other than removing this call?
It appears if I comment out the Http Module registration for Application Insights then this method finishes right away, but as soon as I add them back the method hangs again. There appears to be some problem with the AreaRegistration.RegisterAllAreas() call and Application Insights.
<httpModules>
<!-- removing this makes everything work -->
<!-- <add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" /> -->
</httpModules>
<modules>
<remove name="FormsAuthentication" />
<!-- removing these makes things work -->
<!--
<remove name="ApplicationInsightsWebTracking" />
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" />
-->
</modules>
Yes i have the same situation and what i have done is remove appinsight element and apply xml transformation between debug and release web.config file. This helps me when me want to debug and include appinsight when release.
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<httpModules>
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web"
xdt:Transform="Insert"/>
</httpModules>
</system.web>
<system.webServer>
<modules>
<remove name="ApplicationInsightsWebTracking" xdt:Transform="Insert"/>
<add name="ApplicationInsightsWebTracking" type="Microsoft.ApplicationInsights.Extensibility.Web.RequestTracking.WebRequestTrackingModule, Microsoft.ApplicationInsights.Extensibility.Web" preCondition="managedHandler" xdt:Transform="Insert" />
</modules>
</system.webServer>
Could you provide more details, so we could reproduce this issue?
What operating system do you use (Windows Version)?
Are you running created web application on IIS Express or regular IIS?
If this is regular IIS, what application pool mode do you use (integrated/classic)?
What .NET Framework version you choose to create an application?
What MVC version your application is based on?
Did you enable WebAPI or WebForms for your web app project?
I am using an HttpModule to do some URL shortening on my site. I am using Visual Studio 2008 and IIS 7, and .Net 3.5.
When the module is specified in the system.webServer element of web.config, and the site is run in IIS, it works fine. The config looks like this:
<system.webServer>
<modules>
<add name="MinimizeModule" type="ClipperHouse.UrlMinimizer.MinimizeModule" />
</modules>...
My module attaches to the BeginRequest event, everything works. However, I can't get it to run using the built-in VS web server (Cassini). I tried moving the module config to the system.web element in web.config, no luck. I put a breakpoint on it, nothing happens.
Any thoughts on why this would be an issue?
(I also tried the Application_BeginRequest event in global.asax. Still no luck, though I'd prefer to keep everything in web.config anyway.)
Cassini, the development web server provided with IIS uses the IIS6 module syntax, so you must duplicate the module add like so
<system.web>
<httpModules>
<add name="MinimizeModule" type="ClipperHouse.UrlMinimizer.MinimizeModule" />
</httpModules>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<remove name="MinimizeModule" />
<add name="MinimizeModule" type="ClipperHouse.UrlMinimizer.MinimizeModule"
preCondition="managedHandler" />
</modules>
</system.webServer>
Note that I've also added a precondition to your IIS7 settings
If you are running on IIS 7, put the module in:
<configuration>
<system.webServer>
<modules>
<add name="MinimizeModule" type="ClipperHouse.UrlMinimizer.MinimizeModule" />
</modules>
</system.webServer>
</configuration>
If you are running on Cassini (Visual Studio's integrated miniature web-server), put the module in:
<configuration>
<system.web>
<httpModules>
<add name="MinimizeModule" type="ClipperHouse.UrlMinimizer.MinimizeModule" />
</system.web>
</configuration>
IIS will crash if you give it the Cassini location.
Cassini will crash if you give it the IIS location.
Whenever i deploy, i have to be sure not to deploy web.config. i also include the notes in web.config:
<system.web>
<!--The Cassini location to add modules (comment out for IIS)-->
<httpModules>
<!--WARNING: IIS will crash if you leave this in here.
IISBUG: IIS doesn't support system.web/httpModules,
and Cassini doesn't support system.webServer/modules
-->
<!--Comment out for IIS-->
<add name="PerformanceHttpModule" type="DummyPlaceholder.PerformanceHttpModule"/>
</httpModules>
</system.web>
<system.webServer>
<!--The IIS7 location to add modules (comment out for Cassini)
<modules runAllManagedModulesForAllRequests="true">
<!--IIS7 will crash if you present a system.web httpModules. -->
<remove name="PerformanceHttpModule" />
<add name="PerformanceHttpModule" type="DummyPlaceholder.PerformanceHttpModule"/>
</modules>
</system.webServer>
IIS's left hand doesn't know what Cassini's right hand is doing - and they both screwed it up.
Did you try also putting the module declaration in the element? When running in dev using Cassini, that's usually the place I have to put modules to get them running.