changing dotnet version in IIS causes problem in IIRF

Jun 2, 2010 at 5:56 AM
Edited Jun 2, 2010 at 10:18 AM

I installed the .net framework 4 on my VPS. and changed the .net version from 2 to 4 in IIS. and my IIRF rules started behaving strangely. IIRF was working but url were rewritten wrongly.

like earlier this rule was working fine-

RewriteRule ^/$  /home.aspx [L]

it used to rewrite the incoming url like  to

but as I changed the dot net version to 4 this rule stopped working. and now url of type  go to 404 page

I dont know what is the problem. Do I need to make some changes to change the .net version?


Jun 2, 2010 at 12:59 PM

I don't know - you'll have to examine the logs, determine what's happening and why.

Previously someone reported a problem with ASPNET 4.0 and eurl.axd.   Apparently in some cases where there's an exception, ASPNET 4.0 will generate a URL that includes eurl.axd.

This unexpected URL indicates an exception occurred.  I've seen that URL cause further surprises in IIRF. 

In any case you'll gain some insight by examining the IIRF logs.

Jun 2, 2010 at 5:15 PM

snippet of my  log-

how to resolve this eurl.axd

Tue Jun 01 23:50:41 - 48728 - DoRewrites: Url (no decoding): '/anvil-foundation-addresses-maps-schools-in-Ahmedabad-india/5081/eurl.axd/43d352510f961e4fb5e8999c076ae0ff'
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: depth=0
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 1 : 2 matches
Tue Jun 01 23:50:41 - 48728 - EvalCondition: Cond %{HTTP_HOST} ^schoolsearch\.in$ => FALSE
Tue Jun 01 23:50:41 - 48728 - EvalConditionList: rule 1, FALSE, Rule does not apply
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 2 : 2 matches
Tue Jun 01 23:50:41 - 48728 - EvalCondition: Cond %{HTTP_HOST} ^mail.schoolsearch\.in$ => FALSE
Tue Jun 01 23:50:41 - 48728 - EvalConditionList: rule 2, FALSE, Rule does not apply
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 3 : 2 matches
Tue Jun 01 23:50:41 - 48728 - EvalCondition: Cond %{HTTP_HOST} ^searchschool\.in$ => FALSE
Tue Jun 01 23:50:41 - 48728 - EvalConditionList: rule 3, FALSE, Rule does not apply
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 4 : -1 (No match)
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 5 : -1 (No match)
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 6 : -1 (No match)
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 7 : -1 (No match)
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 8 : -1 (No match)

.Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Rule 57 : 1 matches
Tue Jun 01 23:50:41 - 48728 - EvalCondition: Cond %{REQUEST_FILENAME} !-f => TRUE
Tue Jun 01 23:50:41 - 48728 - EvalCondition: Cond %{REQUEST_FILENAME} !-d => TRUE
Tue Jun 01 23:50:41 - 48728 - EvalConditionList: rule 57, TRUE, Rule will apply
Tue Jun 01 23:50:41 - 48728 - EvaluateRules: Result (length 37):


Jun 2, 2010 at 5:46 PM
Edited Jun 2, 2010 at 5:51 PM

I don't know how to resolve it.

If you do some research into it, you will see that the eurl.axd URL is generated by ASPNET 4.0, in response to an error condition. It indicates an exception.  Exactly what that exception or error condition is, I don't know.  

I've seen the eurl.axd URL once before with someone using IIRF. That person offered a theory that some interaction between ASPNET 4.0 and IIRF is leading to that error condition. At this point it's only a theory.  I haven't tested or investigated this myself.

If you scan the internet, you see lots of people with eurl.axd URLs. And i think it's safe to assume that not all of these people have IIRF. 

If you'd like to understand the problem, I think your first goal should be to determine exactly what causes the eurl.axd. At that point, you may be able to devise a way to avoid the exception.

I'll appreciate it if you share what you learn. 


Jun 2, 2010 at 5:50 PM
Edited Jun 3, 2010 at 5:39 AM

I searched and found this page:

It could be the solution you seek.  It says that ASPNET 4.0 does something special with extensionless URLs, and that ASPNET's action in that regard can interfere with a 3rd-party URL Rewriter. The person who wrote the article found a solution: disabling the ASPNET "special thing" for extensionless URLs.  He uses ISAPI_Rewrite, but I think the same soution would apply to IIRF. 

EDIT: What's required is to make a change in the registry.  Set the DWORD EnableExtensionlessUrls to 0 (zero) within HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.

This fix is also noted on the "breaking changes" page for ASPNET 4.0.

Jun 2, 2010 at 8:17 PM

thanks it worked..


Jun 13, 2010 at 3:28 PM

I am the author article referenced by Cheeso.  The issue I was describing is that I had already completed the described solution on the breaking changes. I am not sure that it has to do with just extensionless URL's. I am still getting errors now just with no path after the long string, /eurl.axd/asdfa34asdfasdfasdfasdfasdf/ is the requests I am still getting. Randomly if you make requests to the site you continue to get the URL in the address bar as that, but it serves the page correctly it seems.

Besides that what I was explaining was that the website and all virtual directories are using 4.0 framework. Unfortunately I am not explicitly turned off the application on the directory so no code executes. The issue is the content being requested in the virtual directory isn't managed content and the content in the root of the application that it is referencing also is not. They are actually flash videos, the main skin swf & flv is in the virtual directory but root of the application holds only the player files. The issue is that I am receiving managed requests where no managed request should be....

In IIS 6 there is no integrated pipeline so none of the requests should be forced through the pipeline without a wildcard mapping....

I am pretty sure that you will get random errors when you setup a 404 catch page in the customerrors section of your web.config. It has to do not only with extensionless urls but something else that Microsoft has yet to explain.


Jun 17, 2010 at 10:14 PM


Same issues here, fine with ASP.NET 2.0 + IIS 6 but eurl.axd strangeness with ASP.NET 4.0 + IIS 6.

I noticed that IIRF was working fine on most pages except the root of my site.

Even then if I visited "/default.aspx" explicitly, IIRF worked fine.

If I visited just "/", though, I got the eurl.axd strangeness. Obviously IIS 6 is finding the default document and triggering the ASP.NET pipeline that way, but something in ASP.NET 4.0 is looking at the original URL ("/"), seeing that it is indeed "extensionless", and doing strange things. I am not sure who to blame (myself, which is usually the case; IIRF; or Microsoft).

For now, I rolled my rewrites into a quick and dirty IHttpModule since I was just doing some basic (www) fiddling. Would love to hear if anyone else runs across this and has any insight on the issue.


Jun 17, 2010 at 10:34 PM
Edited Jun 18, 2010 at 6:41 PM

I take it back. My IHttpModule exhibits the same problem that IIRF does. For now I will keep IIRF and apply the registry hack. Actually, it did work--my browser was just caching a previous bad 301 redirect.

What I said about it working for "/default.aspx" but not "/" still applies, though.


Jun 17, 2010 at 10:47 PM
npiaseck, the reason it works for /default.aspx but not for / , is because the IIS "strangeness" you have seen occurs only with extensionless URLs.
Jun 18, 2010 at 6:47 PM
Edited Jun 18, 2010 at 6:49 PM
Here is what I believe is happening:

The Microsoft-intended scenario:

1. A global ISAPI filter called aspnet_filter.dll runs on every request. If it sees an extensionless URL, it appends "/eurl.axd/some-long-number" to it. The idea is to get the ".axd" in there so that in a default IIS 6 installation, IIS will send this to aspnet_isapi.dll.
2. aspnet_isapi.dll picks up the request (having been mapped there by the ".axd" extension), and the DefaultHttpModule fixes the URL back (removing the "/eurl.axd" stuff) early in the processing pipeline.

The problematic scenario:

1. aspnet_filter.dll runs, sees an extensionless request, and appends "/eurl.axd/some-long-number" to it.
2. IIRF runs next and applies a rewrite rule as appropriate. As per my rule, it dutifully appends the path and query to the redirection, which happens to be "/eurl.axd/some-long-number", since that's all IIRF sees and aspnet_isapi.dll has not yet run to fix up the URL.
3. aspnet_isapi.dll never gets a chance to run to fix it up because IIRF issued the redirect and terminated the request. So the user's *browser* actually tries to go to "/eurl.axd/some-long-number", which goes directly to aspnet_isapi.dll because of the ".axd" mapping, and gets a 404 error, since the machine-level web.config maps "eurl.axd" to the HttpNotFoundHandler.

The reason it works if you go to "default.aspx" is because aspnet_filter.dll sees the ".aspx" and decides not to munge with the URL as it is not extensionless. So IIRF can the work off an untampered URL.


The solution(s):

1. Apply the registry entry to turn off the feature. I have done this and it works fine; I am just pouting because it leaves a bad taste in my mouth. Note that one could still get "extensionless" URLs in ASP.NET--you'd just have to do it the old way, with a wildcard mapping in IIS 6, where everything really did go through aspnet_isapi.dll.
2. Adjust all of your rewrite rules to strip out/ignore the "eurl.axd" oddities. The thought of this does not excite me.
3. Do redirection via your own IHttpModule. By the time it runs, the DefaultHttpModule will have already fixed up the URL. But you lose IIRF's capability to redirect any type of request.
4. Somehow get IIRF to run *before* the global aspnet_isapi.dll filter. To me this is the best option, but I don't know if it's possible or how to do it.
Jun 18, 2010 at 6:57 PM

you can get IIRF to run before ASPNET by configuring IIRF at HIGH priority and ASPNET at MEDIUM, DEFAULT, or LOW priority.  Not sure if this is a good thing to do.  It's possible that ASPNET depends on being HIGH priority, for some other reason.

Also, You can exclude URLs containing eurl.axd from IIRF processing, with a single rule, at the top of your IIRF.ini file, like this:

Rewriterule  eurl.axd - [L]

That would effectively ignore the URL.  I'm not sure if that's what you meant by "strip out/ignore".   If instead you want to strip that stuff that was added, probably a simple rewrite would do it.  If I knew the format of the mangled URL, I may be able to produce a simple IIRF rule that unmangles it.     Once again it should be a single rule at the top of each IIRF.ini file. it shouldn't require modifying every rule.

This latter approach though, would have a similar effect as turning off the eurl.axd stuff in the registry.  I think I might prefer the registry approach, all other things being equal.


Jun 18, 2010 at 7:10 PM
Edited Jun 18, 2010 at 7:12 PM
Well, I wouldn't want to exclude them--it happens to any URL that happens to not have an extension anywhere in it--I just want to strip the stuff that was added. aspnet_filter.dll is essentially adding "/eurl\.axd/[a-z0-9]+/" to the end of URLs that should be stripped out when issuing a rewrite; I could certainly write a rule to do that, but it does seem a little like a pinging-around-a-pinball-machine type of workaround (i.e., one filter inserts the string and the next filter strips it right back out).

Your point about aspnet_filter.dll wanting to run at high priority for other various reasons is a sound one; we're certainly in undocumented territory. Adding the registry entry to my MSI installer was quick and easy.

I think I'm going to stay with the registry entry. Now that I understand what is happening better, it doesn't bother me as much. It seems that the bit about it being triggered by an error/exception (which is what I was concerned about) is a bit of a red herring; that's just one of the ways these things can pop up. The other way is by things (such as IIRF) examining the URL in between aspnet_filter.dll and aspnet_isapi.dll in the pipeline. Since it's Microsoft's hack to get extensionless URLs working by default in IIS 6, and I don't need it nor want it, simply turning it off via the documented registry entry seems to be a reasonable solution.

And if I really wanted extensionless URLs without a wildcard mapping that badly, I wouldn't still be on IIS 6 anyway.

Probably something to consider for the next version's help file though, since I imagine the number of people discovering this is only going to grow and pester you ever more frequently =)
Jun 18, 2010 at 7:13 PM

Well I'm glad you got it sorted.  I thnk you for the comments and insight.  Your suggestion for updating the helpfile is a good one.  I will do that.



Jun 18, 2010 at 7:21 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jul 15, 2010 at 4:17 PM

Alrighty guys. I think we know what the issue is. I disucss it in more detail here