Funny, I see no hands up. I don't like it either, so I have attempted to do something about it.

Near the end of the 'Once again with the hyphens' thread, I put in a rewrite rule for making friendly urls even friendlier, by allowing /page/tabpath/blah to map to /page/tabpath/blah.aspx. This was accomplished using the free Ionic URL Rewriter ISAPI filter thing. I'm not sure if anyone uses it or anything, but this is sort of a carryon from there.

Todays rule/thing:

RewriteCond %{REQUEST_FILENAME}\default.aspx -f
RewriteRule ^(/[^.?/]+?)/*$ /default.aspx?alias=%{HTTP_HOST}$1 [I,L]

Yeah I know, it's hideous. Let me start at the beginning, at 'why DNN does this ugly url thing'.

So, what's up with this /default.aspx?alias=www.mysite.com/child thing?

When you make a DNN child portal that sits under your main site, it creates a folder in the location and drops a default.aspx into it. It does this so that www.mysite.com/child/ will take you to a physical page, which lets it get into asp.net. This default.aspx is where the rewrite happens, and flips you back to the main page but with the url that you wanted as a paramter.

This is pretty bad, and I know it's something that Scott would love to be able to fix with his friendly URLs project, but I don't see it happening, since the /child/ means that it won't even get into asp.net, let alone near his dll. But I digress.

Having this knowledge actually helps us. We know there is a physical file at /child/default.aspx, which -might- be a decent way of telling that the url being visited is a child portal or not.

So let's break down the rule(s) above, using www.mysite.com/child/ as our url.

1. RewriteCond %{REQUEST_FILENAME}\default.aspx -f
- Is the requested file with \default.aspx a file? Checks if c:\inetpub\wwwroot\dnnsite\child\default.aspx is a physical file. We won't touch the rule if it isn't.

2. ^(/[^.?/]+?)/*$

- The requested path starts with a /, and has any number of characters (minimum of 1) that is NOT a (period)(questionmark)(backslash) - and save this string for later, and then ends with any number of /s (incl zero of them).

3. /default.aspx?alias=%{HTTP_HOST}$1 [I,L]

- The actual file to serve up, if we have got this far. We don't show this to the client, we just use this internally to pull up the actual data, the client still sees /child/. %{HTTP_HOST} is replaced with www.mysite.com and $1 is replaced with the string we saved in step 2: /child, and we end up serving a page that has the actual url of /default.aspx?alias=www.mysite.com/child

4. [I,L]

- Ignore the case when checking the urls, and don't continue parsing after this rule is accepted.

Hmm, how does that look, anyone spot any flaws? How about this... If you have any other portals linked to that installation (ie www.mysite.com and www.mydogs.com), you can use /child on the end of each of them, the difference being if alias=www.mydogs.com/child wasn't an actual alias, it would still show www.mydogs.com/chlid whilst displaying the home page... whereas without this rule, it would send you straight back to www.mydogs.com... Another problem, if you actually have a folder that has a default.aspx file, you can't get to it, because this rewrites it away.

So, those are about the only real problems I see with it, and to be quite honest, I can live with them. You could do rules that only work with certain child portals on certain servers, but that means writing individual rules for each child url and server combination. I guess it's a personal thing :)

Anyway, I hope this helps someone. We're using it on our sites when they go live, and it works stella in staging so we aren't expecting anything less in production.

I hope Scott doesn't mind me hijacking a thread about this. I know it's only indirectly related to the friendly urls project that he's done.

Cheers,

Max

PS. If using with the other rule from the other thread, try this:

RewriteCond %{REQUEST_FILENAME}\default.aspx -f
RewriteRule ^(/[^.?/]+?)/*$ /default.aspx?alias=%{HTTP_HOST}$1 [I,L]

RewriteRule ^(/[^.?]+?)/*$ $1.aspx [I,L]

ie, put the new rule above the old one, otherwise the one that adds the .aspx will be kicked off before checking if it is a child portal. Also note the new old one, the old old one wasn't terribly efficient.