Hosting a laravel app in Azure's App Service and every time the web application makes DELETE requests, it throws up 405 Method Not Allowed and returns the message below:
The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used.
I've exhausted all options I could find in the internet and tried all stuff mentioned. Hope someone could help.
If your application uses .NET WebAPI, you may get a 405 Method Not Allowed error when you issue a PUT or DELETE request.
This error is caused because the WebDAV module intercepted the request
In your web.config, try to insert this code
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
</system.webServer>
And this issue duplicate of this question
Related
I am trying to send a delete request to my Web API service via Fiddler and am getting back a 405 "Method not allowed" error.
I have read extensively about removing the "WebDAV" module in web.config and similar suggestions (WebDAV is not enabled in my applicationhost.config anyway), but nothing I have tried has worked.
My service is currently running on IIS Express 10 (launching from Visual Studio). I do have this in my web.config file:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"/>
I would have thought the verb="*" piece would have allowed DELETE, but it does not seem to work.
One other note - when I inspect the response in Fiddler, under the Security heading it says: Allow: GET, POST.
I am not sure where that "Allow" parameter is being set (I am new to Web API).
Any help would be greatly appreciated. Please let me know what other information you need from me and I will add it.
Thank you!
Just reproduced this by creating a new webapi project [targeting .net framework 4.7.1]
Through Fiddler, I can hit the DELETE endpoint without any changes to web.config.
Please make sure to use correct endpoint including the id parameter.
e.g http:localhost:xxxx/api/values/id // please include the id and xxxx is port number.
If http:localhost:xxxx/api/values is used without id , I get the same result 405 Method Not Allowed
Hope this helps.
You can modify the IIS Express applicationHost.config in the %userprofile%\documents\IISExpress\config folder. To enable PUT and DELETE for extensionless Urls scroll down to the bottom of the IIS Express applicationHost.config file and look for a handler entry that starts with: <add name="ExtensionlessUrl-Integrated-4.0".... In the "verb" attribute add PUT and DELETE so the "verb" attribute looks like: verb="GET,HEAD,POST,DEBUG,PUT,DELETE"
Update your web config like this
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule"/> <!-- ADD THIS -->
</modules>
Does anyone know if there is a way of catching this error?
Essentially I'm trying to implement some functionality to allow a user to upload a file from a webpage to a webapi controller.
This works fine, but if the file size exceeds the maximum size specified in the web.config the server returns a 404 error.
I want to be able to intercept this and return a 500 error along with message which can be consumed by the client.
I can't work out where to do this in WebApi as the Application_Error method I've implemented in Global.asax is never hit and it seems like IIS is not passing this through to the WebApi application.
Try to set IIS to accept 2GB requests(in Bytes).
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" /> // 2GB
</requestFiltering>
</security>
</system.webServer>
And set reasonable request size for ASP.NET app(in kiloBytes).
<system.web>
<httpRuntime maxRequestLength="4096" /> // 4MB (default)
</system.web>
Now IIS should let requests less than 2GB pass to your app, but app will jump into Application_Error reaching 4MB request size. There you can manage what you want to return.
Anyway, requests greater than 2GB will always return 404.13 by IIS.
Related links:
Dealing with large files in ASP.NET Web API
How it looks like on my server:
<system.web>
<httpRuntime targetFramework="4.6.1" maxRequestLength="16240" />
</system.web>
I have both WebDAV installed and running on my site, as a virtual sub site i have a MVC WebAPI site, the API works great, until I try to send a PUT request to it, then i get the below error:
HTTP Error 500.21 - Internal Server Error
Handler "ExtensionlessUrlHandler-Integrated-4.0" has a bad module "ManagedPipelineHandler" in its module list
If I disable WebDAV, then everything works fine and I get no errors. This only happens when WebDAV is enabled.
I have all of the following code in my web.config:
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="false">
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="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>
</system.webServer>
I've tried messing with various app pools.
I've also tired all of the things mentioned in all of these questions:
How to get rid of this error Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Handler "ExtensionlessUrlHandler-Integrated-4.0" has a bad module "ManagedPipelineHandler" in its module list
How to fix: Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
None of this has solved my issue, is there anything else out there that I have not tried?
We ended up going to Microsoft with this, they reviewed it for several weeks before coming back saying that it's not possible to run WebDAV and WebAPI in the same site.
They will try to address this issue in a future release of IIS.
#jblaske has a good response.
If you want to remove it temporarily then maybe this article is the best solution.
If you want to remove the handler all together then follow these steps.
Open IIS and go to the site in question.
Click on "Handler Mappings"
Find the handler named "WebDAV"
Select it and Remove it
This is my original post.
I started getting this error after I removed WebDAV module and handler manually from IIS to get PUT working. I had to remove "WebDAV Publishing" server role to get over this error. After removing this role and restarting the IIS, PUT is working fine.
You might have a typo issue in the declaration of handlers. Thomas Marquardt's Blog says
5.0 Troubleshooting
If you receive an error similar to the one below, your
section is probably invalid.
HTTP Error 500.21 - Internal Server Error Handler "" has
a bad module "ManagedPipelineHandler" in its module list You probably
have a handler mapping that does not have the correct precondition.
IIS is not forgiving in regard to typos, and preconditions are
case-sensitive. The text must be preCondition=”integratedMode” or
preCondition=”classicMode”.
Also, another suggestion from the comments on that article:
Andrew Johnson 25 Jan 2011 3:20 AM #:
I found that I can also get the "Handler has a bad
module ManagedPipelineHandler in its module list" if the handler has
requireAccess="None". For me, changing this to requireAccess="Read"
made the error go away.
That comment might apply to your case as I see that in applicationHost.config the entry for WebDav handlers is (note the requredAccess="None"):
<add name="WebDAV" path="*" verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK" modules="WebDAVModule" resourceType="Unspecified" requireAccess="None" />
Found an alternate for this issue.
When the patches of the server were pushed,The default framework were set back to 2.0.
Re register .Net framework by going to framework 4.0 folder C:\Windows\Microsoft.NET\Framework64\v4.0.30319
Executing the command aspnet_regiis -I
Check the web.config to match the .Net framework version
Go to IIS -> Application pool, set the .Net framework values to 4.0
Restart the IIS.
I am trying to set up http custom error pages in my MVC 3 web application. I have added the following to my web.config:
<httpErrors errorMode="Custom" defaultResponseMode="ExecuteUrl" defaultPath="/Error/404">
<clear />
<error statusCode="500" path="/Error/404"
</httpErrors>
When a 500 error occurs on a request I expected this to redirect the user my.domainname.com/Error/404.
I have an Error controller which contains one action called error, I have mapped requests for 404 to this action.
When I force a 500 error (verified by chrome developer tools network tab) on the website I receive a blank page with the following message:
"The page cannot be displayed because an internal server error has occurred."
If I remove the httpErrors section from my web.config then I get the actual exception message. Therefore the httpErrors section I have in the web.config must be working, I just do not understand how to set it up correctly.
Here is a list of the attributes I have picked and why:
errorMode="Custom": So that I can see the custom error page and verify it is working before changing it to local only.
defaultResponseMode="ExecuteUrl": This should allow me to specify a server relative url as the path, which sounds like what I want as I want to hit a controller action.
defaultPath="/Error/404": The relative url I want requested if I do not specify one.
Edit:
I should add that the site is running on IIS 7.5. I also do not wish to use the tag as this is designed to work with IIS 6 and should be used for IIS 7+.
Try using the customErrors section in the web.config (inside system.web) instead.
http://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx
e.g.
<customErrors mode="On">
<error statusCode="404" redirect="Error/404" />
<error statusCode="500" redirect="Error/500" />
</customErrors>
It should be like Controller/Action/Id. In your case Action is missing. Check following example and change it as per your action methods...
<system.web>
<customErrors mode="On" defaultRedirect="/Error/Index/" >
<error statusCode="401" redirect="/Error/NoAccess/" />
<error statusCode="404" redirect="/Error/NotFound/" />
</customErrors>
....
</system.web>
I want to implement the recently approved PATCH HTTP verb in a RESTful service implemented with ASP MVC 3. I have added the following settings in the web.config file.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="PATCHVerbHandler" path="*" verb="PATCH" modules="ProtocolSupportModule" requireAccess="None" />
</handlers>
<security>
<requestFiltering>
<verbs>
<add verb="PATCH" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
</configuration>
The action method is decorated with the AcceptVerbs("PATCH") attribute.
The service works properly with the PATCH verb. The URL gets routed to the right action method and returns the proper data.
The strange issue is if I using a different URL that does not match any routes using the PATCH verb, IIS returns "200 OK" instead of "404 Not Found". All the standard verbs (GET, PUT, DELETE, POST, HEAD, OPTIONS) do not have this problem.
Do I need to register additional handlers for the PATCH verb or is it a routing issue? Any help is appreciated.
You don't actually need a custom handler to process HTTP requests made with the PATCH verb; instead, you may want to keep decorating your actions with the AcceptVerbs("PATCH") attribute while checking that the ASP.NET ISAPI is configured to handle any verb (it is the default), including PATCH.
If you have to handle this kind of requests using a custom module, by the way, please keep in mind that it is the responsibility of the handler itself to set the status code for each request (including the ones it should handle, according to the mapping, but it can't for whatever reason) and maybe it is not setting the correct value upon finishing.