POSTing to a re-written URL on IIS 6 doesn't work

Question

I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).

I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:

var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;

(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).

The "pretty" URL is something like this:

http://www.site.com/admin/user/edit/

On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.

I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.

If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.

Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.

[edited because somehow the code above lost its code highlighting]

Answer 1

The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.

This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx

Answer 2

It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:

• Right click on the relevant website and select "Properties"
• Choose the "Home Directory" tab
• Click "Configuration" down in the "Application settings"
• Click "Insert" next to the "Wildcard application maps"
• Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
• Untick "Check that file exists"
• Click "OK" back through the Russian doll of dialogs.

This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.

The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?

Answer 3

I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:

when IIS initially executes a custom URL on a 404 error, it changes POST to GET, even if the client does a POST request.

(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).

Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:

RewriteCond %{REQUEST_FILENAME}  !-d
RewriteCond %{REQUEST_FILENAME}  !-f
RewriteRule ^(.*)$               /Default.aspx?404;http://%{HTTP_HOST}$1  [U,L]

And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.