03:59:57 PM
3KC0YAKID
LOL. Big bucks, right :-) Sometimes it doesn't feel like that :-)
I actually can't take credit for this. I think it was James Blackburn who pointed this out a while ago... I knew about the UrlRewrite module of course and I know that ASP.NET hooks into the UrlRewriting pipeline of IIS do something similar to provide their routing - their basically routing to default.aspx in MVC, but are also completely rewriting the request paths so that the native URL comes back in the request.
The reason I had put this off was mainly because I couldn't think of a clean way to provide the URL and then figure out some way to use it effectively. I'd been playing with Wildcard extensions which was very problematic and put it aside...
I think the way the implementation works is pretty nice (with getting the original URL and pre-parsing it) but it would definitely be nicer if the actual paths returned in the request were properly fixed up so it's more seamless.
I've been thinking about this a bit though. It might be possible to automatically detect a rewrite operation as part of a low level ProcessHit request (by looking for a rewrite header). It would then be possible to completely re-write the URL before anything else gets hit which means everything would work as before. RouteRequest then would also have to check for the header and if it finds it route to wwProcess::UrlRewrite - that way you'd get the same functionality as above, but with proper URLs.
Hmmm... this looks like a bit of work though and digging into the low level stuff of Web Connection that I try to avoid mucking with these days :-)... but it sounds possible. Not sure if it's worth the time investment though... You'd still have to use the UrlRewrite module and point at SOME url (at that point it could be any URL that hits the Process class).
+++ Rick ---
I'm still doing a LOT of testing with this but initially, I'd say this is right on the mark. My only concern right now is preserving the original request audit trail (i.e. now I have a list full of hits to UrlRewriteHandler.ww instead of ThisPage.ww and ThatPage.ww) but I can think of a dozen ways to deal with that. I just wanted to give you some quick feedback that this seems to fit the bill perfectly.
And what's awesome is that this has been there like YEARS and instead we're writing custom 404 handlers and crap... why didn't I see this solution before <g>. I guess that's why you make the big bucks! I'll report back in just a bit.
Hi all,
Since this topic has come up a bit in recent months I've posted a detailed blog post on how you can accomplish extensionless URLs with Web Connection and the IIS Rewrite Module. Starting forward with the next version some of the code mentioned in the blog post is integrated into Web Connection's wwProcess class going forward.
You can check out the blog post here:
Extensionless Urls with Web Connection and the IIS UrlRewrite Module
+++ Rick ---
West Wind Technologies
Making waves on the Web
from Maui, Hawaii