The HTTP verb POST used to access path ‘/’ is not allowed.
Recently, I posted on my Google+ account how I was dealing with an incredibly frustrating problem with an ASP.NET website we migrated to our new IIS hosting server. After several days of on and off research into this problem, and discussions with the site’s developers, a variety of blogs and tech articles finally revealed the cause of the problem.
Symptoms:
The most frustrating part of this problem were the oddly specific symptoms it was showing. The website’s default page contains a login form in order to proceed further into the “member’s only” site. When you would navigate to the site as anyone normally would (www.***.com) the above error would occur. However, if you explicitly defined the default page (www.***.com/default.aspx) the login would work without issue. Researching this issue was troublesome as many articles were unrelated, and the few articles or forums that were similar failed to have a resolution, only work-arounds.
Problem:
Quite obviously, the problem is with the Handler Mappings. For some reason, IIS was incorrectly assigning an isapi mapping if the URL did not contain a specific extension (.aspx, for example).
After some discussion with the developers it was discovered that the site contained Response.Redirects, which would eventually lead to the discovery of the problem:
Service Pack 1 for Windows 2008 R2 breaks ASP.NET routing
Special thanks to this blog: http://www.shanmcarthur.net/Default.aspx?DN=7d0cd525-bbc5-46c3-8096-95f93827aeea
Resolution:
As stated in the blog above, a fix can be located here: http://support.microsoft.com/kb/980368
However, this problem can also be resolved (if you have access to IIS) by simply removing (without coding) the ExtensionlessURLHandler mappings from the Handler Mappings of the website.
As soon as I had removed these mapping entries, the problem was instantly resolved.
The Nitty-Gritty:
Now that I’ve given you the overall details of this problem, I’d like to share the, in my opinion, amusing story of how this all went down.
Last week, Piast Technology officially launched our new Windows 2008 R2 x64 IIS/ASP.NET hosting server which is now available to all clients requiring ASP.NET hosting. The first site to be hosted on this server is an ASP.NET site developed by one of our clients. The site was completed and had gone through beta testing on the client’s development server. All that was left to do was migrate the site to our live production environment and we were ready to roll.
All custom IIS settings were exported from the development server (with an identical OS/IIS setup as our server) and then imported (with code and SQL database) into our production environment. All necessary security configurations were applied, and the site was started.
At first glance, the site appeared to be working correctly. However, when we tested the login functionality absolutely nothing happened. The site was developed to suppress errors, so we would had to look at the server logs to figure out the problem. There, we discovered, was the following ASP.NET error:
Exception information:
Exception type: HttpException
Exception message: The HTTP verb POST used to access path '/' is not allowed.
Now, I hate to admit things like this, but I had never seen this error before; neither had any of the developers. Immediately, I understood that there was an issue with the Handlers… but it did not make any sense. The IIS settings between the two servers were identical. Why was this working on one server and not the other?
My first step in troubleshooting this issue was to try to explicitly define the page I was trying to use. Instead of simply going to the site, I went to thesite/default.aspx and tested again. This time, the login worked as it should.
Obviously, an easy work-around for this problem would be to set up a redirect to simply forward any attempt at access “/” to “/default.aspx”. However, going back to the developers and politely asking them to change their code because our server was doing something funny is exactly a habit I intend to get into.
Researching this problem was, as it turns out, incredibly difficult. It seemed that almost nobody had an issue like this before… and the fact that it was working on the development box, but not on our brand new production server only added fuel to the frustrating fire. What were we doing wrong? I was concerned that this would reflect negatively on our business.
Finally, after working with the developers, more details were revealed that would finally lead us to the resolution. The site utilizes Response.Redirects in the Site.Master to point all POST forms, etc… directly back to the page. Because this code was required for every page (not just the default page), the action could not be specifically defined to point to default.aspx.
This revelation would lead us to a forum discussion concerning a similar problem involving AJAX. While the details were not exactly the same, it did point us in the right direction. The Response.Redirects were involved in the problem, and the solution for most people was to remove the wildcard (Static File, etc…) handlers for the Handler Mappings. After some trial and error, we finally discovered that by removing the ExtensionURLHandler mappings the login functionality would work as it should.
It seems that by doing this, we were forcing IIS to dig a little deeper to find what it was supposed to be doing with the POST information it was receiving.
Hooray! The problem was solved.
Last night, however, I couldn’t sleep. It was driving me mad. Why was our server different from the development server? I can’t live with an “I dunno… but it works now, hurr” type of answer to this problem. Fortunately, armed with the latest knowledge of how we fixed the problem, I was able to more accurately research the issue.
Finally, I discovered the following blog article: http://www.shanmcarthur.net/Default.aspx?DN=7d0cd525-bbc5-46c3-8096-95f93827aeea
This new personal hero of mine spelled out exactly the problem we were having and why. As it turns out, the development server did not have Service Pack 1 for 2008 R2… and our’s did.
It was that simple…
and now that the feeling of “I’m so stupid… why didn’t I catch that” has subsided, I am just completely stoked that this is no longer a mystery issue and I’ll get some sleep tonight.




