Life after FPSE (Part 4)

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.

Listing content in virtual directories

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.

Setting up two sites

Another idea that I've implemented on a few web sites lately is to use two web sites that point to the same content:

  • The first web site (e.g. www.example.com) is used for normal HTTP web browsing
  • The second web site (e.g. authoring.example.com) is used for for WebDAV authoring

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:

  • Each web site can have separate security settings (anonymous versus authenticated).
  • Log file data will be kept separate for browsing versus authoring activity.
  • Each web site can have a separate apppool, and the authoring apppool can be configured to ignore delegated configuration; this configuration helps alleviate problems from uploading invalid Web.config files that might otherwise prevent HTTP access to your web site.
  • Each web site can have separate request filtering rules - this alleviates having to configure the "applyToWebDAV" attribute on your request filtering settings.
  • You can have separate SSL requirements for each site - your "www" site can be HTTP-only and your authoring site can be HTTPS-only.
  • Virtual directories on the "www" site would not automatically be added to the authoring site, so you can "hide" content from your authoring activities. For example, if you have a set of library scripts that your web site uses that you want to prevent authors from trying to update, you can deploy them through a virtual directory on the "www" site and it will remain hidden from the authoring web site until it's explicitly added.

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.

No Comments