I have been developing an application that was hosted on IIS 6 and we have just upgraded our server that uses IIS 8.5 but can't get it to work on the new server.
The application has a custom handler that's called when a file with extension .XmlDataTypes is requested.
For this to work in IIS6 I set up a mapping as:
Extension: '.XmlDataTypes'
Path: 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll'
Verbs: All.
In Web.config:
<httpHandlers>
<add verb="*" path="*.XmlAmenityData" type="XmlHandler"/>
<add verb="*" path="*.XmlDataTypes" type="XmlDataTypes"/>
</httpHandlers>
And this works fine.
In IIS8.5 I've tried adding a Managed Handler with:
Requested path: '*.XmlDataTypes'
Type:, selected 'XmlDataTypes'
Name: XmlDataTypes
This then added to the web.config file:
<system.webServer>
<handlers>
<add name="XmlAmenityData" path="*.XmlAmenityData" verb="*" type="XmlHandler" resourceType="File" preCondition="integratedMode" />
<add name="XmlDataTypes" path="*.XmlDataTypes" verb="*" type="XmlDataTypes" resourceType="File" preCondition="integratedMode" />
</handlers>
</system.webServer>
When I run a page that requests a URL with extension .XmlDataTypes via a jQuery function I just get an 404 not found error.
Thanks in advance for any help.
J.
It looks like those are files on your disk. If they are, your solution could be as simple as adding the following to your web.config under "system.webServer".
<staticContent>
<mimeMap fileExtension=".XmlAmenityData" mimeType="application/xml" />
<mimeMap fileExtension=".XmlDataTypes" mimeType="application/xml" />
</staticContent>
That's it.
However, if you are really relying on HTTP Handlers, please note that the "Type" need to be fully qualified with the assembly name at the least.
So your type need to include the namespace as well.
In your code, "XmlHandler" isn't fully qualified with the namespace and the assembly isn't mentioned. Ensure that it is.
Finally, change the "resourceType" to "Unspecified" or IIS will ensure that a file truly exist before executing your handler.
None of the answers I've found here or on similar questions on stackoverflow worked for me.
I'm using IIS 8.5, .Net v4.0, Integrated, and was still getting a 404 with the following handler config:
<system.webServer>
<handlers>
<add name="testEmail" path="*.em" verb="*" type="MyApp.testRazorEmailHandler, MyApp" resourceType="Unspecified" requireAccess="Script" />
</handlers>
</system.webServer>
I enabled tracing and found the following :
116. -HANDLER_CHANGED
OldHandlerName testEmail
NewHandlerName System.Web.Mvc.MvcHandler
NewHandlerModules ManagedPipelineHandler
NewHandlerScriptProcessor
NewHandlerType System.Web.Mvc.MvcHandler, System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
As you can see it looks like it had correctly picked up the request using my custom HttpHandler testEmail but MVC had stolen it.
I opened my route definitions in RouteConfig.cs and found that adding:
routes.IgnoreRoute("{resource}.em");
I got it to ignore requests meant for my Handler.
Hope this helps someone - I was tearing my hair out!
Related
We have an ASP.NET Core 2.0 web site that also presents a couple of simple Web API methods for UI enhancement purposes.
The Web API calls work as expected when running locally under IIS Express, but when we deploy to our IIS 8.5 production web server, we get the following error when making HTTP DELETE and PUT requests...
405 Method Not Allowed
After some web searching, we have found several posts suggesting the removal of the IIS WebDAV module. We have disabled this in IIS (it is our server), and we have also tried the following:
Disabled WebDAV
Enabled WebDev and set Allow verb filtering = False
Set the Hander Mappings to allow All Verbs in the Request Restrictions settings for: aspNetCore, WebDAV and ExtensionlessUrlHandler-Integrated-4.0
None of the above steps have resolved our problem.
Any advice/direction would be much appreciated.
This was what worked for me (netcore 2.0)
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
</system.webServer>
Found here: https://www.ryadel.com/en/error-405-methods-not-allowed-asp-net-core-put-delete-requests/
After hours of research and trial and error, the fix seems to be pretty simple. Add a Web.config file to your .NET Core 2.0 application:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- To customize the asp.net core module uncomment and edit the following section.
For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="aspNetCore" />
<remove name="WebDAV" />
<!-- I removed the following handlers too, but these
can probably be ignored for most installations -->
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="aspNetCore"
path="*"
verb="*"
modules="AspNetCoreModule"
resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
</configuration>
Hope this helps.
Whilst removing WebDAV may solve your issue, you may be wondering (like I was), what is WebDAV and what is it used for?
I found this page which helps explain it:
https://www.cloudwards.net/what-is-webdav/
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
This worked well for me in .Net Core 2.1
In my case, I got the 405 error for .Net 5 Web API PUT and DELETE calls. I tried multiple solutions like removing WebDAV (Turn Windows features on or off -> IIS -> World Wide Web Services -> Common HTTP feature -> WebDAV Publishing) doesn't work, editing WebDAV entry in "Handler Mappings" messed up the application.
Solution
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
Add the following lines to your web.config file. That does it.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,PUT,DELETE,DEBUG" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Ftms.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
Remove the WebDAV Publishing from IIS server. Its come under the Internet Infromation service -> Common Http Features
https://ignas.me/tech/405-method-not-allowed-iis/
In my case, I resolved the issue after I add requireAccess="None" to aspNetCore handler
Like this :
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" requireAccess="None" />
For me, I resolved the issue after I noticed I was trying to post to the client domain instead of the API. [facepalm]
I didn't even have a mapping for aspnetcore under Handler Mappings in IIS. It made me open Visual Studio Installer and install Development time IIS support under .NET cross-platform development. Then, the aspnetcore handler mapping showed up in IIS.
If you're developing with recent ASP.NET Core version and using development server it's likely that it's not a WebDAV issue at all.
Make sure that your routes and HttpDelete/HttpPut attributes are set correctly. Otherwise you'll get the same or similar errors if the method is simply mismatched (e.g. route to a HttpGet one was chosen).
After long research on the internet, I solved it as follows;
<configuration>
<system.webServer>
<modules>
<remove name="ModSecurity IIS (64bits)" />
<remove name="ModSecurity IIS (32bits)" />
</modules>
</system.webServer>
To prevent WebDav from getting enabled at all, remove or comment 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
This worked well for me in .Net Core 2.2
I hope that you can help me with the below problem.
I am using ASP.NET MVC 3 on IIS7 and would like my application to support username's with dots.
Example: http://localhost/john.lee
This is how my Global.asax looks like: (http://localhost/{username})
routes.MapRoute(
"UserList",
"{username}",
new { controller = "Home", action = "ListAll" }
);
The applications works when I access other pages such as http://localhost/john.lee/details etc.
But the main user page doesn't work, I would like the app to work like Facebook where http://www.facebook.com/john.lee is supported.
I used below code and it didn't work for me at all:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
I was able to use below code and get the app to accept dots but I definitely wouldn't like to use below code for many different reason, please tell me there is a way to overcome this problem.
<modules runAllManagedModulesForAllRequests="false" />
Add a UrlRoutingHandler to the web.config. This requires your url to be a bit more specific however (f.e. /Users/john.lee).
This forces every url starting with /Users to be treated as a MVC url:
<system.webServer>
<handlers>
<add name="UrlRoutingHandler"
type="System.Web.Routing.UrlRoutingHandler,
System.Web, Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
path="/Users/*"
verb="GET"/>
</handlers>
</system.webServer>
Just add this section to Web.config, and all requests to the route/{*pathInfo} will be handled by the specified handler, even when there are dots in pathInfo. (taken from ServiceStack MVC Host Web.config example and this answer https://stackoverflow.com/a/12151501/801189)
This should work for both IIS 6 & 7. You could assign specific handlers to different paths after the 'route' by modifying path="*" in 'add' elements
<location path="route">
<system.web>
<httpHandlers>
<add path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" />
</httpHandlers>
</system.web>
<!-- Required for IIS 7.0 -->
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
<validation validateIntegratedModeConfiguration="false" />
<handlers>
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer>
</location>
I was facing the same issue. So the best solution for me is:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"></modules>
<system.webServer>
For anyone getting an 'Cannot create abstract class' exception when using the UrlRoutingHandler approach, it's likely due to:
Using a restricted 'path' (e.g. path="/Files/*") in your web.config declaration, and
A folder/path with the same name exists in your project
I don't think the dot is the problem here. AFAIK the only char that should not be in the user name is a /
Without seeing the route that matches john.lee/details it's hard to say what's wrong, but I'm guessing that you have another route that matches the url, preventing the user details route from being matched correctly.
I recommend using a tool like Glimpse to figure out what route is being matched.
I have a webservice which defines a custom httpmodule. I am attempting to launch this webservice onto a production server running IIS7 but have only been able to get it to run in Classic mode.
I have tried moving this section
<system.web>
<httpModules>
<add name="BasicAuthenticationModule" type="MyProject.UserAuthenticator.UserNameAuthenticator" />
</httpModules>
...
To the system.webserver section like so:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="BasicAuthenticationModule" type="MyProject.UserAuthenticator.UserNameAuthenticator" />
</modules>
When I try this IE gives me this error:
Config Error
Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to
'BasicAuthenticationModule'
I also attempted to migrate automatically with the following DOS command:
appcmd migrate config "mysite/"
And get this message back:
The module BasicAuthenticationModule with type "mytype" is already present in the application with a different type"", and was not migrated
I am not an IIS expert so any insights are appreciated.
So after a little research it appears there is already a native module called BasicAuthenticationModule. I can eliminate my issue by renaming my module "BasicCustomAuthenticationModule." Is this the correct approach or should I be removing the other one?
Thanks!
AFrieze
Their was a conflict in the name BasicAuthenticationModule. The solution was to rename the module.
<httpModules>
<add name="BasicCustomAuthenticationModule" type="MyProject.UserAuthenticator.UserNameAuthenticator" />
</httpModules>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true">
<add name="BasicCustomAuthenticationModule" type="MyProject.UserAuthenticator.UserNameAuthenticator" />
</modules>
I have an asp.net website using the form controls from Telerik. It's just moved to a new server but I keep getting a 500 Internal Server Error.
Removing the httpHandlers section of the web.config makes server error go away, although then it complains if there is a Telerik control on the page. The whole config file is valid XML. Is there anything wrong with this code?
<httpHandlers>
<add path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResource, Telerik.Web.UI, Version=2008.2.826.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" validate="false"/>
</httpHandlers>
I see you mention it has just moved to a new server. Was this an IIS6 to IIS7+ migration?
IIS7 uses <system.webServer\handlers> instead of the IIS6 <httpHandlers> section. On top of this it will throw an error by default if you have the settings in the old section even if the new section is populated correctly.
Try this:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
<!-- modules here -->
</modules>
<handlers>
<!-- modules here -->
<add name="Telerik.Web.UI.WebResource" path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResource, Telerik.Web.UI, Version=2008.2.826.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" />
</handlers>
</system.webServer>
The validateIntegratedModeConfiguration="false" will allow you to keep your httpHandlers section populated without throwing an error (useful if you are debugging on a cassini / iis6 server) and the entry in the <handlers> section will configure it for your IIS7 server.
The runAllManagedModulesForAllRequests="true" is not strictly required but you will probably find yourself needing it if you are new to configuring IIS7 :)
Is the new server perhaps running IIS7?
Then try this
<system.webServer>
<handlers>
<add path="Telerik.Web.UI.WebResource.axd" verb="*" type="Telerik.Web.UI.WebResource, Telerik.Web.UI, Version=2008.2.826.20, Culture=neutral, PublicKeyToken=121fae78165ba3d4" validate="false"/>
</handlers>
</system.webServer>
Also, make sure you have the exact version that you have specified in the Handlers section. You do not actually need the Version, Culture, and Public Token parameters specified in your web.config in order for it to work. They are there incase you are using more than one version in your application. Without them being specified, the server will use the first one that it finds referenced in your project. So, if you are only using one version of an assembly, you can omit the parameters.
Make sure that you have the Telerik DLL Telerik.Web.UI.dll referenced in your project and that CopyLocal is set to "true". Also, make sure (using File | Properties) that you have the right version on the server, too.
I am having problems trying to map an HttpHandler in the web.config.
This is the relevant config bit:
<httpHandlers>
<add verb="*" path="*.hndlr" type="MyAssembly.MyHandler, MyAssembly" validate="false" />
</httpHandlers>
When I navigate to http://localhost/myApp/whatever.hndlr I am getting a server error 404 (not found).
It's the 1st time I am hooking up an HttpHandler so I might be missing something - any help appreciated!
UPDATE:
I managed to get it working using both answers so far - who's able to explain why it works gets the answer marked!
This is my config (won't work if you don't have both - I am running IIS7 in classic mode)
System.web:
<httpHandlers>
<add verb="*" path="*MyHandler.hndlr" type="MyAssembly.MyAssemblyHandler, MyAssembly" validate="false"/>
</httpHandlers>
System.webserver:
<handlers>
<add name="MyHandler" verb="*" path="*MyHandler.hndlr" type="MyAssembly.MyAssemblyHandler, MyAssembly" validate="false" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script"/>
</handlers>
Are you using IIS7, if so is the application pool running in classic or pipelined mode? If it is IIS7 in pipelined mode then the handler reference needs to go into the following section
<system.webServer>
<handlers>
</handlers>
<system.webServer>
rather than in the following section.
<system.web>
<httpHandlers>
</httpHandlers>
</system.web>
Just as a guide for those stuck with this problem I found the crucial attribute to be..
resourceType="Unspecified"
I originally followed a Microsoft example to set this up and they had it as
resourceType="File"
which just kept giving me 404 errors. My HTTPHandler is returning graphics.
Hope this helps :)
i am using IIS7, the solution is:
in section
<system.web>
<httpHandlers>
<add verb="*" path="*.ashx" type="CVOS.MyDocumentHandler"/>
</httpHandlers>
<system.web>
and section
<system.webServer>
<handlers>
<add name="pdfHandler" verb="*" path="*.ashx" type="CVOS.MyDocumentHandler" />
</handlers>
</system.webServer>
What is the extension of your handler? If you are using a custom extension like .hndlr you may also need to add a ScriptMap in IIS and point it to the ASP.NET runtime so that IIS can forward the request to the correct processor.
In IIS7 go to your website
Under the IIS group go to Handler Mappings
Under Actions click Add Script Map
Set Request Path to *.hndlr
Set Path to the ASP.NET runtime (%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll) or whatever version you are running.
Then in your web.config you will need to register the handler in the appropriate section as described in the other answer.
It is also possible to experience this error if you have set up the handler for 32 bit, but you are running in 64 bit (or vice versa). It's easy to set up both and have all the bases covered.
Note "preCondition", and "scriptProcessor" differences.
<handlers>
<add name="MyHandler_32bit" verb="*" path="*MyHandler.hndlr" preCondition="bitness32" type="MyAssembly.MyAssemblyHandler, MyAssembly" validate="false" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" />
<add name="MyHandler_64bit" verb="*" path="*MyHandler.hndlr" preCondition="bitness64" type="MyAssembly.MyAssemblyHandler, MyAssembly" validate="false" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" />
</handlers>
None of the previous answers worked for me.
I'm using IIS 8.5, .Net v4.0, Integrated, and was still getting a 404 with the following handler config:
<system.webServer>
<handlers>
<add name="testEmail" path="*.em" verb="*" type="MyApp.testRazorEmailHandler, MyApp" resourceType="Unspecified" requireAccess="Script" />
</handlers>
</system.webServer>
I enabled tracing and found the following :
116. -HANDLER_CHANGED
OldHandlerName testEmail
NewHandlerName System.Web.Mvc.MvcHandler
NewHandlerModules ManagedPipelineHandler
NewHandlerScriptProcessor
NewHandlerType System.Web.Mvc.MvcHandler, System.Web.Mvc, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
As you can see it looks like it had correctly picked up the request using my custom HttpHandler testEmail but MVC had stolen it.
I opened my route definitions in RouteConfig.cs and found that adding:
routes.IgnoreRoute("{resource}.em");
I got it to ignore requests meant for my Handler.
Hope this helps someone - I was tearing my hair out!
Hopefully my solution will help others. On a server move from IIS6 to 7.5, both .Net 4.0 Integrated, I had a Captcha control that quit working. It turns out that removing this attribute preCondition="integratedMode,runtimeVersionv2.0" from the <add> node in <system.webserver><handlers> resolved the issue.
This seems to be an edge case, but I had a customer where our httpHandler used in our application did not work on any of their servers. The handler pointed to an .ashx page and it was called from JavaScript.
The handler mapping showed up in IIS, the handler factory was there, but I would get a 404 when the browser requested the ashx page associated with the handler. After many different attempts to fix we finally browsed to the file in IIS on the server and it specifically showed a 404.7 being returned with this message.
•Request filtering is configured for the Web server and the file extension for this request is explicitly denied.
•Verify the configuration/system.webServer/security/requestFiltering/fileExtensions settings in applicationhost.config and web.config.
If you get this then Request Filtering is enabled for the .ashx extension at either your app or site level. Go to the Request Filtering option in IIS at both your site and app level and verify that the extension is not blocked. There are two different ways Request Filtering can be configured.
The default seems to be that it explicitly blocks only file extensions that are configured in the list (blacklist). The other way it can be configured is that only files specifically configured as allowed in the list are let through (whitelist). This second option is how the customer had configured all of their Windows Servers by default and it turns out that the .ashx file extension was not in the list of allowed extensions.
This is the first thread that appears when I look for a verb that responds with a 404. In my case the solution was a configuration of VS
Tools > Options > Web projects > [x] Use 64 bit version
Sorry, my VS is in spanish