4

I'm trying to perform what I understand to be a relatively simple task. I'd like to remove the extensions from the URLs on my website. I have the proper set up in my application to handle and rewrite the URLs - the trouble is I can't get past IIS to actually get to my application without the extensions.

The details:

I'm running IIS6 on Windows Server 2003. I've gone into the web site for my application, gone to the home directory tab, clicked "Configuration" and added a wildcard map to the following file:

c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll

Which I verified is the same as what is used above in the application extensions portion by .ascx, etc.

If I navigate to http://mywebsite.com/Blogs the result is as follows:

HTTP/1.1 404 Not Found
Content-Length: 1635
Content-Type: text/html
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 14 Jan 2010 15:04:49 GMT

Which seems to be a standard IIS 404 message. If I navigate to http://mywebsite.com/Blogs.aspx I get my ASP.NET app....

How can I troubleshoot this? I feel like I've double checked everything a dozen times but to no avail. I must be missing something obvious.

Update: Here are the exact instructions given by the asp.net url rewriter that I'm using:

IIS 6.0 - Windows 2003 Server

  • open property page for website / virtual directory.
  • click the 'home directory' tab
  • click the 'configuration' button, select the 'mappings' tab
  • click 'insert' next to the 'Wildcard application maps' section
  • browse to the aspnet_isapi.dll (normally at c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll)
  • Ensure that 'check that file exists' is unchecked
  • Click OK, OK, OK to close and apply changes

Update 2:

I have yet to find a resolution for this. The application does not seem to be receiving the request from IIS, any further ideas?

Ian Robinson
  • 65
  • 1
  • 2
  • 9
  • You mention that you do have a custom URL/route handler in your app. Is that one that you wrote or is it a third party library? – squillman Jan 18 '10 at 14:48
  • It is a third party handler, more information on that can be found here: http://www.ifinity.com.au/Products/Support_Forums/forumid/8/threadid/3847/scope/posts. I've been troubleshooting it from that end as well, but at this point it still appears that the request is not actually getting to the application at all. – Ian Robinson Jan 19 '10 at 13:07
  • Ah, so this is a DotNetNuke site then? – squillman Jan 19 '10 at 15:15
  • If so, which version of DNN are you using? I'll see if I can replicate your environment and help come up with something. – squillman Jan 19 '10 at 15:34
  • Yep. This particular site is DNN 4.8.4. I'm actually setting up a new 4.8.4 site now on my personal server (windows server 2003, IIS 6) to see if I can replicate the issue. I got it working in my dev environment (DNN 5 / IIS 7) in no time. – Ian Robinson Jan 19 '10 at 16:13
  • Hmmm....test worked successfully on that go around. Followed the exact same steps... I'm going to explore the web.config of the problem site in more detail to see if there is something is keeping the handler from getting loaded. – Ian Robinson Jan 19 '10 at 16:19

2 Answers2

3

The 404 is because ASP.NET is not finding a file called "Blogs". It's just saying that all files should be processed (interpreted) by aspnet_isapi.dll

You will need to put something (a custom routing engine or a URL rewriter) in place that maps URL's to files. Try Helicon's ISAPI Rewrite or Ionic's Isapi Rewrite.

squillman
  • 37,883
  • 12
  • 92
  • 146
  • 2
    Hm, my understanding was - as long as I don't have 'verify that file exists' checked in the wildcard settings - that the request would be forwarded to my asp.net application. Is that not the case? – Ian Robinson Jan 14 '10 at 15:29
  • 2
    The request, yes. But it still needs to know how to find the file. Unless you have a custom handler that knows how to take /Blogs and turn it into /Blogs.aspx it's not going to work. ASP.NET doesn't know how to do that by default. – squillman Jan 14 '10 at 15:51
  • OK, I do have a handler set up on the application itself that should be handling requests that it receives and mapping to the appropriate page. So, are you saying that the request IS actually getting forwarded to my application and the problem may not actually be in IIS? I can look into the configuration of the httphandler based product that is being used further if that is the case. – Ian Robinson Jan 14 '10 at 15:58
  • Yes, that's where I'd look. Confirm that your app's handler is actually getting the request from IIS. So yeah, the text in my original answer is not quite right, going back and rereading it. I'll fix that. – squillman Jan 14 '10 at 16:04
  • BTW- here's a good post about this topic. http://scottonwriting.net/sowblog/posts/943.aspx – squillman Jan 14 '10 at 16:06
  • so is the X-Powered-By: ASP.NET in the server's response the clue that I was missing to tell me that the problem wasn't actually in IIS or would that be there either way? – Ian Robinson Jan 14 '10 at 16:08
  • No, that header gets set even if ASP.NET doesn't come into the picture. For example, you'll see that header in the response for a .txt file without any wildcard mappings (ie- when IIS processes the static content). – squillman Jan 14 '10 at 16:12
  • The answers are correct so far, but to add further info, the real issue is partially a default doc issue too. I bet that http://mywebsite.com doesn't work either. You have to specifically type in http://mywebsite.com/default.aspx. Once you've given ASP.NET access to all files (in IIS6), then IIS steps back and doesn't try to resolve the default docs. It doesn't know if /blogs should be /blogs/default.aspx, /blogs.aspx or what. A great way to tell what IIS does is using process monitor without the wildcard mapping and see what IIS does in the background. – Scott Forsyth Jan 14 '10 at 18:41
  • As noted, ISAPI Rewrite is a good solution, but you'll need to take into account both the default docs and the URL Rewriting for blogs.aspx. (ASP.NET MVC can take care of that part of you). – Scott Forsyth Jan 14 '10 at 18:42
  • I discovered that the web.config only had one of the two required entries to wire up the handler properly. I can't believe I overlooked that. Your answer was exactly right. – Ian Robinson Jan 19 '10 at 16:42
  • Rock on :) Glad it's working now! – squillman Jan 19 '10 at 16:44
0

When you configuring the IIS, there are two "check that files exists". there's one when you trying to Insert and that must remain unchecked (as your original instruction above suggests). and the second one is in the listing where all type of extensions are listed, you select .aspx and click Edit, there tick the check box. this will make it work. thanks.