In continuation from my previous blog posts on on the subject of migrating from FPSE to WebDAV, today's blog post will address a combination of issues that I've run into and some implementation ideas.
One different that I ran into rather quickly after I migrated a couple of web sites from FPSE to WebDAV was that suddenly my virtual directories were visible in my web authoring tool, which is Microsoft Expression Web. By default, virtual directories didn't show up when using FPSE - you had to explicitly "install" FPSE on individual virtual directories in order to use them from FrontPage or Visual Studio over the FPSE protocol.
For one web site this was somewhat alarming, because I had a web site with only 200 web pages and a virtual directory with thousands of files in it, and I routinely create VBA macros to automate large-scale authoring actions. This meant that any use of the ActiveWeb.AllFiles collection would take a large amount of time to process.
There isn't any easy way to hide virtual directories from WebDAV, because they're not necessarily hidden from any HTTP requests. If your web sites use virtual directories, WebDAV simply makes them available. You can't use IIS 7 Request Filtering's "hidden segments" or "deny sequences" to hide these paths, although you can use those to prevent access.
The only way that you can more or less "hide" your virtual directories would be to set the authoring rules to allow access to no one. Here's how this might work: you create a web site where you enable WebDAV at the root and add an authoring rule for yourself. Once that is completed, you would click on your virtual directory in the tree view and bring up the WebDAV authoring rules for that path. You would first remove the authoring rule for yourself, then add a new rule that denies all users any access to the virtual directory path.
What the above steps actually do is to instruct the WebDAV module to deny everyone access, so all PROPFIND requests for that path will result in an HTTP 403 response, therefore most WebDAV clients will not display the path. In my particular case I implemented these steps and my web site authoring is back to the way that I expected things to be.
Another idea that I've implemented on a few web sites lately is to use two web sites that point to the same content:
This configuration yields a number of great benefits, but it's not always possible. For example - if someone else is hosting your web content, they might not want to give you a second web site, or they might charge you for two web sites.
Just the same, here's my short list of some reasons why using a second web site for your WebDAV authoring might be a good idea to look into:
That's just a few of the benefits that I've been seeing from deploying WebDAV in a two-site configuration - I'm sure that there are a great deal more reasons why this might be a great idea if you can afford to deploy a site this way.
That's all for today - I hope this gives you some more ideas to think about.