Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

ASP.NET MVC HttpVerbs.Delete/Put Routes not firing


:P
On this page:

A few times in the last weeks I’ve run into a problem where I found that DELETE operations would not fire in ASP.NET MVC controllers. I’ve been building APIs mostly with Web API until recently, but started using MVC instead with current projects in light of vNext which essentially uses the MVC model for ‘APIs’. And I ran into trouble each time with PUT and DELETE verbs not firing.

What’s the Problem?

To demonstrate here’s a simple action method on an MVC controller that uses Attribute routing for a delete operation:

[Route("albums/{id}")]
[AcceptVerbs(HttpVerbs.Delete)]
public ActionResult DeleteAlbum(int id)
{
    var albumBus = new AlbumBusiness();

    if (!albumBus.Delete(id, saveChanges: true, useTransaction: true))
        throw new CallbackException("Couldn't delete album: " + albumBus.ErrorMessage);

    return Json(true, JsonRequestBehavior.AllowGet);
}

When this route is fired I’m getting a 404 error from IIS – it’s not finding the route. However, if I change the route to a HttpVerbs.Get it runs just fine.

What the heck is happening here?

Missing Verbs on ExtensionlessUrlHandler

The main culprit is the ExtensionlessUrlHandler Http handler that’s responsible for handling MVC’s Controller and Attribute routing. The default entry for this handler is defined in ApplicationHost.config doesn’t include the DELETE or PUT verb.

Here’s what’s in my ApplicationHost.config which determines the default handler settings:

<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." 
verb="GET,HEAD,POST,DEBUG"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"
responseBufferLimit="0" />

Note that PUT and DELETE are not among the supported verbs.

To fix this you can add the following to your application’s web.config file:

 <configuration>
<
system.webServer> <handlers> <remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*."
verb="GET,HEAD,POST,DEBUG,PUT,DELETE,OPTIONS"
type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0" /> </handlers> </system.webServer> </configuration>

And voila, PUT and DELETE now work. Yay!

ASP.NET MVC doesn’t, Web API does

It’s interesting to note that the problem above applies specifically to ASP.NET MVC projects. When you create a new MVC project there’s no custom handler registration made. So for MVC project or any project other than an API project you’ll have to manually add the handler – even if you add WebAPI features later.

If you create an ASP.NET WebAPI project you do get the following in the default web.config created by the new project template:

<system.webServer>
  <handlers>
    <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
    <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" 
type="System.Web.Handlers.TransferRequestHandler
"
preCondition="integratedMode,runtimeVersionv4.0"
/> </handlers> </system.webServer>

For me this was probably the main reason for confusion – I expected it to ‘just work’ since I never had an issue with WebAPI. But clearly different default configuration settings are made for API vs MVC applications (so much for ‘One ASP.NET’).

In a way I suppose this makes sense – if you’re not building API applications PUT and DELETE are unlikely to be something needed, but still it’s confusing to have things work sometimes and not others.

Additional Issues: WebDav

If you’re running an MVC application and you run into this issue, most likely the ExtensionlessUrlHandler is the culprit. However, if that does not resolve the issue, there are a few other things to check:

If you have WebDav installed on your server/site, that causes a more restrictive URL/routing rules to be applied including removing the DELETE verb by default.

<system.webServer> <security> <requestFiltering> <verbs applyToWebDAV="false"> <add verb="DELETE" allowed="true" />
<add verb="PUT" allowed="true" /> </verbs> </requestFiltering> </security> </system.webServer>

If you are using WebDav as part of your application or it’s defined at the server root, you can add additional verbs to the RequestFiltering section to explicitly allow the verbs you’re interested in through.

Alternately if you want to disable WebDav in your specific application:

<system.webServer>
  <modules runAllManagedModulesForAllRequests="false">
    <remove name="WebDAVModule" />
  </modules>
</system.webServer>

If you’re not using WebDav as part of your application (but it’s defined at the server root) you can just remove the module and the restrictions should actually go away.

Posted in ASP.NET  IIS7  MVC  

The Voices of Reason


 

Ivo Botusharov
April 21, 2015

# Great information

Thank you very much for your investigation and the provided information. I was just wondering why in ASP.NET MVC 5 scaffold templates the data annotation on the Delete action methods is: [HttpPost] instead of [HttpDelete] which would be more appropriate in terms of http standard. Thanks again!

Dawid
September 08, 2015

# re: ASP.NET MVC HttpVerbs.Delete/Put Routes not firing

I am migrating my project from MVC 4 to MVC 5 and I just have faced this ridiculous problem. Thank you very much for sharing this information, you help me save a lot of time!
Microsoft is going crazy...

Keith W.
October 28, 2022

# re: ASP.NET MVC HttpVerbs.Delete/Put Routes not firing

I faced the same problem for days trying to figure out why a new Web API 2.0 with Get, Post, and Puts would not do my Put calls and returned 404s for those. Wish I had found this post sooner. Thanks for posting. I added the ExtensionlessUrlHandler-Integrated-4.0 handler to web.config and it worked immediately. Great job and thanks for posting such valuable info. I really enjoy your site. Always great info on it. Thanks


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024