we have an application pool that has a slower initialization time after an app pool recycle in IIS 10. (around 5-7 seconds after recycle then 30-50 ms after the first request.)
I have done some research and found that the "Application Initialization." module should do the trick.
I installed it onto the server and set the application pool to "AlwaysRunning" and the corresponding site to "PreloadEnabled == True." After making those changes we tested by recycling and the response times seemed a bit better...down to 3 to 4 seconds after recycle. I tried to then disable the "overlapped recycle" to see if that helped and again it did a bit better 1.5 to 2 seconds after recycle and then 20 to 30 ms after the first request.
Question is: Is that the best we can expect? I was hoping there would be away to fully pre-warm the app pool so that even the first request is around a few ms. The issue is that test messages we are sending to the API are small and the ones in Prod would be much larger so an initialization of 3-4 seconds could be much much longer in Prod.
Following are the steps you can perform to Auto Initialize application hosted on IIS –
• Installed Application Initialization feature - IIS 8.0 Application
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization
• Make sure the warmup.dll (which should load from C:\Windows\SysWOW64\inetsrv\warmup.dll or from C:\Windows\system32\inetsrv\warmup.dll depending on the bitness of your process) present
• Configure the app pool to be always running (from the advanced properties)
eg. In the applicationHost.config (%WINDIR%\system32\inetsrv\config\applicationHost.config) file the application pool setting looks like this –
<add name="PreLoadApp" autoStart="true" managedRuntimeVersion="" startMode="AlwaysRunning">
<processModel idleTimeout="00:00:00" />
</add>
• Scroll down a little more in applicationHost.config to the configuration element. Within that section there will be an entry, modify your application as below
<site name="PreLoadApp" id="5">
<application path="/" applicationPool="PreLoadApp" preloadEnabled="true">
<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\PreLoadApp" />
</application>
• Then selected the site from the IIS manager tree view on the left-hand side and go to the configuration editor.
this time underneath the <system.WebServer/applicationInitialization>
tag, and look at the list of requests
set the request to only target a page called (host header is optional) and also you can provide a query string
q=abhi // to identify if request is coming from preload only.
set the doAppInitAfterRestart parameter to true and apply the
settings
And you should be good by now, try recycling your application pool, it should Initialize and warmup automatically.
You can refer these MS docs to know more about Application Initialization and configuration steps –
https://learn.microsoft.com/en-us/iis/configuration/system.webServer/applicationInitialization/
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization
IIS saves doAppInitAfterRestart in the web.config of the application, which might be overwritten by future deployments. Therefore I'd put the web.config under source control and make it part of the deployed artifact.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
<!-- Add this node to web.config -->
<applicationInitialization doAppInitAfterRestart="true">
<!-- Only needed when website contains multiple child apps -->
<add initializationPage='/hangfire',hostname='' />
<applicationInitialization />
</system.webServer>
</configuration>
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 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.