Re: Handling Default Document without that Default Document existing

Custom routing in the Process class to the right method is exactly what we do (in our App specific subclass of wwProcess). It's not generic, in fact, it's very rigid and "hard codey". However, it is very efficient. It basically looks for some key element in the URL, like for our Sku detail pages it's "/sku-", finds the parameter, makes sure that's a valid sku, then compares the current correct other parts of the URL, like in "/red-widgets/sku-123.htm" it would be making sure there that was what was asked for, and if so, passes control to the "ShowDetail" method, if not, 301 redirects to the proper URL (so that changes we make don't kill SERP link juice mainly). This means if we change "example.com/red-widgets/sku-123.htm" to "example.com/shiny-red-widgets/sku-123.htm", everything is properly 301 redirected. It also means that "example.com/bogus/sku-123.htm" or anything else doesn't properly 404 like it should but that's not as big a deal as losing page rank effort.

Rick, it's been my experience that if you create a scriptmap for say ".ww" and then add a default document at the website level of say, "index.ww", IIS will 404 (i.e. NOT route to wc.dll) unless the subdirectory structure asked for in the URL exists (and I think even that the file index.ww exists in the asked for subdirectory structure), OR you have provided the ".ww" as part of the URL. For example, this will work:

example.com/no-such-directory-exists/mypage.ww

but this will not route to index.ww:

example.com/no-such-directory-exists/

however, this will route to index.ww:

example.com/any-subdirectory-that-really-exists/

Hope that makes sense.

What I was looking for was a way to make it work without having to provide a specific scriptmap in the URL (i.e. it would default to index.ww) and where the subdirectory and file do not have to exist.

The file doesn't have to exist. Nor the directory. but the scriptmap does because that's how the routing to wc.dll (or the .NET WebConnectionModule.dll) works.

You can also set up a wildcard handler (*) and that will route to Web Connection properly, but... and it's a big but... when you do that you'll lose any capability to auto-route.

Basically what you'd need to do is this:

In yourServer::Process():

Handle the OTHERWISE clause and provide your own logic to route to a Process class

Create a custom wwProcess class that has custom logic to route your requests to the right method

I guess I should look into this some more and see if we can come up with a generic mechanism to make this work, but it's tricky. Basically you'd need some sort of 'route table' to tell Web Connection which Process Class it should map to. So we'd have to have some custom routing mechanism similar to the way in ASP.NET MVC which auto-routes.

When I get some spare cycles I can look into that, but I know some folks have done this before with custom logic in their applications.

+++ Rick ---

Now, I understand the basics of why that subdirectory has to exist and why that file has to exist but my question is, can this be modified easily? If so we could more easily build an MVC type routing structure for Web Connect that would also be cleaner.

~Brett

---