I have an ASP.NET Core 2.0 API I am deploying to an Azure App Service. This has been working fine until recently when I had to process a request that took longer than 2 minutes to complete and I got a 502 Bad Gateway stating
"The specified CGI application encountered an error and the server terminated the process".
This consistently happens when I hit the 2 minute mark on this process.
My diagnostic logfile says
018-05-25 02:07:01.462 +00:00 [Error] Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware: An unhandled exception has occurred while executing the request
System.Threading.Tasks.TaskCanceledException: A task was canceled.
I am working on the assumption that this is a timeout issue because it is always at the 2 minute mark and I know the request takes more than 2 minutes to complete. So I was looking into how to increase the timeout and found some posts on SO that talked about using an applicationHost.xdt file, placing it in the root of the Site folder for the site. I am using this XML;
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.applicationHost>
<webLimits xdt:Transform="SetAttributes(connectionTimeout)" connectionTimeout="00:05:00" />
</system.applicationHost>
</configuration>
When I upload it, using Kudu debug console, to the root of the Site folder for my deployment slot I am using to test my API and then look at the transform file, I see the following;
2018-05-24T19:34:19 Start 'site' site extension transform
2018-05-24T19:34:19 StartSection Executing SetAttributes (transform line 4, 16)
2018-05-24T19:34:19 on /configuration/system.applicationHost/webLimits
2018-05-24T19:34:19 Applying to 'webLimits' element (no source line info)
2018-05-24T19:34:19 Set 'connectionTimeout' attribute
2018-05-24T19:34:19 Set 1 attributes
2018-05-24T19:34:19 EndSection Done executing SetAttributes
2018-05-24T19:34:19 Successful 'D:\home\site\applicationHost.xdt' site extension transform
which to me looks like it successfully applied the XDT transform.
However even after restarting the base App Service and the related deployment slot. I am still getting the error.
So, am I using the wrong timeout setting?
When I look at the web.config file in my slots sites/wwwroot folder, it contains only this...
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Mypp.dll"
stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
</system.webServer>
I expected to see the information about the connectiontimeout that was in the XDT file I applied. So, perhaps this is not the right web.config file?
I am not an Azure expert and at this point, I feel like I am wasting time so I wanted to check an see if anyone has any suggestions.
requestTimeout:
Specifies the duration for which the ASP.NET Core Module waits for a response from the process listening on %ASPNETCORE_PORT%.
In versions of the ASP.NET Core Module that shipped with the release of ASP.NET Core 2.0 or earlier, the requestTimeout must be specified in whole minutes only, otherwise it defaults to 2 minutes.
You could try to add the requestTimeout="00:20:00 in web.config in your slots sites/wwwroot folder.
<aspNetCore
requestTimeout="00:20:00"
processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="staging" /> <!-- value could be "development", "staging" or "production"-->
</environmentVariables>
</aspNetCore>
For more details, you could refer to this article to learn about ASP.NET Core Module configuration reference
I have created an MVC Web Api for some university coursework, that works as expected on my development machine (Running VS11).
However when I deploy the application to the webserver on 123reg HttpVerbs other than GET and POST appear to not reach my application at all, initially a 401 Not Authorised response was returned; however after turning off the "WebDAV" module as suggested here these 401s became 405 Method not allowed. In this case I only disabled the handlers as disabling both the handlers and the module meant that my application did not start at all (Error 500 without a stacktrace [custom errors are off]).
I am planning to utilise the forms membership provider to add authentication capabilities to my API, however I removed any [Authorise] attributes from my code when 401s began appearing.
Applications on 123Reg's shared hosting are run under Medium trust.
I have been in contact with 123Reg support, and they have been semi helpful, but have since decided that they cannot help me further (They suggested adding HttpHandlers as detailed below) (Apparently, I should consult a web designer...)
Things I have tried:
I have added [AllowAnonymous] Attributes to my controllers and/or actions with no effect.
I have added the authorization web.config attribute allowing all verbs and paths to all users both authenticated and not:
<authorization>
<allow users="*" />
<allow users="?" />
<allow verbs="*" users="*" />
<allow verbs="*" users="?" />
</authorization>
I have added (As suggested by 123Reg):
<system.webServer>
<handlers>
<remove name="WebDAV" />
<add name="PUTVerbHandler" path="*" verb="PUT" modules="ProtocolSupportModule" resourceType="Unspecified" />
<add name="DELETEVerbHandler" path="*" verb="DELETE" modules="ProtocolSupportModule" resourceType="Unspecified" />
</handlers>
</system.webServer>
This appeared to be a step forward, as we now receive 405 responses rather then 401 respones, however I am now unable to make any further progress. Additionally I have also added:
<httpHandlers>
<add verb="*" path="*" type="System.Web.Mvc.MvcHttpHandler"/>
</httpHandlers>
This also made no difference.
Any help you can give would be much appreciated (I dont really want to have to move host for this application!)
This post solved my problem. I did all the regular things: added all the necessary <handlers> entries, disabled WebDAV, but I still had 401.3 Unauthorized.
Enabling forms authentication solved the problem:
<system.web>
<compilation debug="true" targetFramework="4.0" />
<authentication mode="Forms" />
</system.web>
I found this: http://forums.iis.net/t/1163441.aspx
From the looks of that forum post, you need to completely uninstall WebDAV for the PUT and DELETE Verbs to work. This is not going to help on a shared webhosting scenario unfortunately.
For me it was something different.
I had to go to the site folder, open the security tab for the folder, press Edit button to change group or user names permissions, find the site from my IIS 8 sites and give it a full control permission.
I have written a site that uses ASP.NET MVC Web API and everything is working nicely until I put it on the staging server. The site works fine on my local machine and on the dev web server. Both dev and staging servers are Windows Server 2008 R2.
The problem is this: basically the site works, but there are some API calls that use the HTTP PUT method. These fail on staging returning a 404, but work fine elsewhere.
The first problem that I came across and fixed was in Request Filtering. But still getting the 404.
I have turned on tracing in IIS and get the following problem.
168. -MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName IIS Web Core
Notification 16
HttpStatus 404
HttpReason Not Found
HttpSubStatus 0
ErrorCode 2147942402
ConfigExceptionInfo
Notification MAP_REQUEST_HANDLER
ErrorCode The system cannot find the file specified. (0x80070002)
The configs are the same on dev and staging, matter of fact the whole site is a direct copy.
Why would the GETs and POSTs work, but not the PUTs?
For those of you who do not have WebDAV enabled but are still running into this issue using MVC 4's Web API's...
Steve Michelotti documented a solution that worked for me here.
At the end of the day, I enabled all verbs (verb="*") to the ExtensionlessUrlHandler-Integrated-4.0 handler in my web config.
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
Those IIS servers have web-dav module installed on them and i bet it is not needed and it was installed because the person installing ticked all boxes.
Just remove web-dav from iis.
Alternatively use web.config to remove web dav module:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
...
It seems there are a number of reasons that this occurs. None of the above quite worked for me. I already had the ExtensionlessUrlHandler settings in web.config with all the required HTTP verbs. In the end I had to make the following changes in IIS:
In IIS select your website and double-click Handler Mappings
Find ExtensionlessUrlHandler-ISAPI-4.0_32bit and double-click
In the dialog that appears, click Request Restrictions
On the Verbs tab add the missing HTTP verbs separated by commas (in my case it was PUT and DELETE
Click Ok where required and answer Yes in the Edit Script Map dialog that pops up.
Repeat for ExtensionlessUrlHandler-ISAPI-4.0_64bit
Hope this helps somebody :)
My hosting provider could NOT uninstall WebDAV as this would affect everyone.
This, runAllManagedModulesForAllRequests="true" , worked but was not recommended.
Many fixes included removing the module for WebDAVModule but that still didn't work. I removed the handler also, and finally I could use all verbs POST GET PUT DELETE.
Remove WebDAVModule and WebDAV in modules and handlers.
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
I fixed this removing the UrlScan ISAPI filter
In my case, none of these solutions applied.
I fixed it by changing my app pool to Integrated instead of Classic.
The handler:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
is not going to work with a Classic app pool, since its preCondition is integratedMode.
Rick Strahl from West-Wind recommended the following:
< handlers>
< remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
< add name="ExtensionlessUrlHandler-Integrated-4.0"
path="*."
verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"
/>
< /handlers>
Which Worked very well for me.
Hi For me none of the solutions worked. I finally got it working doing this :
1) In IIS select you application.
2) Go to Request Filtering
3) Then select the HTTP Verbs tab
4) I found the PUT and other verbs to have allowed to false but wasn't able to just edit so I removed the verb then either in the pane on the right select allow verb or right click on the list and select it. Enter the verb you're having troubles with and voilà !
Hope this will help someone !
I resolved this by changing my application pool for the website to Integrated mode when it was previously on Classic mode.
I had an application that was running on IIS 6. All requests went through aspnet_isapi.dll. This was achieved via a wildcard application mapping (which did not verify the file existed).
I have copied said application to a machine running IIS7, and would like to get it working again.
In the application, any request with an extension of .aspx (or .ashx) are handled in the normal way. Other requests with different extensions (such as .html and .xml) are handled by a custom http module. Some requests have no extension, and are dynamically redirect to a file with an extension (e.g. visiting …/item/1 might redirect to …/item/1.html or …/item/1.xml, depending on values in the accept header).
The new location probably does not exist, but a response is generated dynamically.
Currently, the application pool is in “classic” mode, and is using .NET v4.0 (it was previously using .NET 3.5, but that doesn’t seem to be related to the problem). The custom http module is set only in the web.config.
The redirect (from …/item/1 to …/item/1.html) seems to work, which suggests that extension less requests are indeed being processed by the application (that redirect is written in the application itself). I think that means that the custom module is working.
Requests with extensions (.html, .xml etc) are failing however. The error I get is:
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Module: IIS Web Core
Notification: MapRequestHandler
Handler: StaticFile
Error Code: 0x80070002
I have tried:
Adding a wildcard script mapping that mapped * to aspnet_isapi.dll
Tried adding a specific mapping for *.html to aspnet_isapi.dll
These still result in the same error message, and still seem to go to the handler "StaticFile".
I tried modifying "StaticFile" so that it uses the aspnet_isapi.dll executable, and this results in a new error:
HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.
Handler: Not yet determined
Any help would be greatly appreciated.
Set application pool in integrated mode and set that all request run all managed modules
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
...
</modules>
...
</system.webServer>
Use this config in service config it worked for me.
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.serviceModel>
<services>
<service name="WcfService.Service1">
<endpoint address=""
binding="basicHttpBinding"
bindingConfiguration="secureHttpBinding"
contract="WcfService.IService1"/>
<endpoint address="mex"
binding="mexHttpsBinding"
contract="IMetadataExchange" />
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="secureHttpBinding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpsGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
</configuration>
I use WebClient type to upload *.cab files to my server. On the server side, I registered a HTTP handler for *.cab file with the PUT method as below:
<add name="ResultHandler" path="*.cab" verb="PUT" type="FileUploadApplication.ResultHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
But I always get a "405 method not allowed" error. The response said the allowed methods are as below:
Headers = {Allow: GET, HEAD, OPTIONS, TRACE
Content-Length: 1293
Content-Type: text/html
Date: Fri, 27 May 2011 02:08:18 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET}
Even if I explicitly allow the PUT method in the IIS Request Filtering for my web application, the same error still occurs.
I suspect this is a IIS related issue. I'm hoping someone could shed some light on this for me.
Often this error is caused by the WebDAV module that try to handle this kind of requests. An easy solution is to remove it from modules and from handlers of the system.webServer section just inside your web.config file.
Here a configuration example:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
I enabled the Failed Request Tracing, and got the following info:
<EventData>
<Data Name="ContextId">{00000000-0000-0000-0F00-0080000000FA}</Data>
<Data Name="ModuleName">WebDAVModule</Data>
<Data Name="Notification">16</Data>
<Data Name="HttpStatus">405</Data>
<Data Name="HttpReason">Method Not Allowed</Data>
<Data Name="HttpSubStatus">0</Data>
<Data Name="ErrorCode">0</Data>
<Data Name="ConfigExceptionInfo"></Data>
</EventData>
So, I uninstalled the WebDAVModule from my IIS, everything is fine now~
The IIS tracing feature is very helpful.
I tried most of the answers and unfortunately, none of them worked in completion.
Here is what worked for me. There are 3 things to do to the site you want PUT for (select the site) :
Open WebDav Authoring Rules and then select Disable WebDAV option present on the right bar.
Select Modules, find the WebDAV Module and remove it.
Select HandlerMapping, find the WebDAVHandler and remove it.
Restart IIS.
Taken from here and it worked for me:
Go to IIS Manager.
Click on your app.
Go to "Handler Mappings".
In the feature list, double click on "WebDAV".
Click on "Request Restrictions".
In the tab "Verbs" select "All verbs" .
Press OK.
I had this problem with WebDAV when hosting a MVC4 WebApi Project. I got around it by adding this line to the web.config:
<handlers>
<remove name="WebDAV" />
<add name="WebDAV" path="*" verb="*" modules="WebDAVModule"
resourceType="Unspecified" requireAccess="None" />
</handlers>
As explained here: http://evolutionarydeveloper.blogspot.co.uk/2012/07/method-not-allowed-405-on-iis7-website.html
Best to just remove the unused WebDAV feature. Go to Programs and Features => Turn Windows Features On or Off and disable WebDAV Publishing under
Internet Information Services => World Wide Web Services => Common HTTP Features
Removing the WebDAV-module should be sufficient. Just change your Web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule" />
Here is what worked for me:
Open up IIS and click on your Site.
Double Click on the Modules
Right Click on WebDavPublishing and remove.
Restart running WebSite.
I was using Angular 8 and was .NET core API.
I add the following in my service web.config file. That resolve my error.
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
I had the same problem, with a RESTful API running on aspnet core.
I didn't want to uninstall the WebDAV, and I tried most of the remedies described above. I tried to set the verbs="*" both on the site and on the server itself, but without success.
What did the trick for me was the following:
IIS Manager -> Sites -> MySite -> HandlerMappings -> aspNetCore -> Edit
-> Request Restrictions -> Access -> None (it was Script).
After that everything worked, even if I replaced the original WebDAV options.
Another important module that needs reconfiguring before PUT and DELETE will work is the options verb
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="OPTIONSVerbHandler" />
<remove name="WebDAV" />
<add name="OPTIONSVerbHandler" path="*" verb="*" modules="ProtocolSupportModule" resourceType="Unspecified" requireAccess="Script" />
</handlers>
Also see this post: https://stackoverflow.com/a/22018750/9376681
For whatever reason, marking WebDAVModule as "remove" in my web.config wasn't enough to fix the problem in my case.
I've found another approach that did solve the problem. If you're in the same boat, try this:
In the IIS Manager, select the application that needs to support PUT.
In the Features View, find WebDAV Authoring Rules. Double-click it, or select Open Feature from the context menu (right-click).
In the Actions pane, find and click on WebDAV Settings....
In the WebDAV Settings, find Request Filtering Behavior, and under that, find Allow Verb Filtering. Set Allow Verb Filtering to False.
In the Actions pane, click Apply.
This prevents WebDAV from rejecting verbs that it doesn't support, thus allowing a PUT to flow through to your RESTful handler unmolested.
Another tip from me. I have used PHP + IIS, and the Handler Mappings for PHP did not have the PUT verb.
Go to IIS Manager->Your site->Handler Mappings->PHPxx_via_FastCGI->Request Restrictions->Verbs, then add PUT.
That's it!
I had the same issues with PUT, PATCH and DELETE but didn't have anything with WebDav installed. Resolution 1 in this article finally helped me: http://support.microsoft.com/kb/942051
for asp.net core 5
IIS-> Sites -> MySite -> HandlerMappings -> aspNetCore -> Request Restrictions -> Access -> None (it was Script).
For me this error wouldn't go away and allow PUT methods, whatever i did.. uninstalled webdav, put configuration in web.config to remove webdav from handlers and modules, and set up PUT as an allowed verb on the request filters on iis.. and ensure iis handler mappings handling the request had PUT configured..
My problem was eventually due to bad installation of ASP.NET 4.5 Extensions. Removed everything related to asp.net from server roles and features. restarted. readded the roles and restarted. everything worked with above config.
--- The below will make PUT be accepted, but will send it to the wrong handler. --ignore the below
finally, adding PUT verb as allowed verb on TRACE handler mapping on iis worked.. since i had enabled failed error tracing, and this verb was not allowing the verb.
last time i had the same problem on another server's IIS, it was due to a missing '/' at the end of the URL since it was using a default handler without using the default document probably and now i realize that.. so check IIS handler mappings if nothing else helps.
I had this problem but nothing related to WebDAV was the issue. In my case, the client was sending a POST to www.myServer.com/api/chart. This call should be handled by the "ExtensionlessUrlHanlder-Integrated-4.0", however, somehow a local file structure was created in my server directory "...\Server\api\chart\". This meant that the "StaticFile" handler was being called instead. Deleting those local files finally solved the problem.
For Windows server 2012 -> Go to Server manager -> Remove Roles and Features -> Server Roles -> Web Server (IIS) -> Web Server -> Common HTTP Features -> Uncheck WebDAV Publishing and remove it -> Restart server.
I have a same problem for PUT and DELETE request in IIS10 for asp.net core 5.
I just added below lines in web.config and problem is resolve.
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
You can do solve by other way from IIS also.
In IIS, select the application
Add rules to allow HTTP verbs in Request Filtering (But this alone doesn't work).
Go to "Modules", then select the "WebDAV Publishing" module and remove it.
Go to "Handler Mappings", then select the "WebDAV" and remove it.
in cmd run IISRESET
This is my solution, alhamdulillah it worked.
Open Notepad as Administrator.
Open this file %windir%\system32\inetsrv\config\applicationhost.config
Press Ctrl-F to find word "handlers accessPolicy"
Add word "DELETE" after word "GET,HEAD,POST".
The sentence will become <add name="PHP_via_FastCGI" path="*.php" verb="GET,HEAD,POST,DELETE"
The word "PHP_via_FastCGI" can have alternate word such as "PHP_via_FastCGI1" or "PHP_via_FastCGI2".
Save file.
Reference: https://learn.microsoft.com/en-US/troubleshoot/iis/http-error-405-website
If you are only developing on your machine, using IIS to run your application and you are not going to use WebDAV then just go to Control Panel > Add or Remove Windows features and disable WebDAV
If IIS app pool is running under classic mode, make sure you have the following in your web.config
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE" modules="IsapiModule" scriptProcessor="c:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" />
In my case I had relocated Web Deploy to another port, which was also the IIS port (not 80). I didn't realize at first, but even though there were no errors running both under the same port, seems Web Deploy was most likely responding first instead of IIS for some reason, causing this error. I just moved my IIS binding to another port and all is well. ;)
To prevent WebDav from getting enabled at all, remove the following entry from the ApplicationHost.config:
<add name="WebDAVModule" />
The entry is located in the modules section.
Exact location of the config:
C:\Windows\System32\inetsrv\config\applicationHost.config
In case anyone still using ASP classic needs to solve the method not allowed trouble for ASP, you also need to re-register the ASP classic handler for telling it to handle additional verbs. By default, it only handles GET, HEAD and POST.
<system.webServer>
<!-- other stuff ... -->
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ASPClassic" />
<add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST,PUT,DELETE,PATCH" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="File" />
</handlers>
</system.webServer>
In order to remove WebDAV module and handler using appcmd you can use this:
appcmd uninstall module WebDAVModule
appcmd clear config -section:system.webServer/handlers -"[name='WebDAV']"
This can also be use in a release pipeline if needed.