Rewriting the URL Path

I've spent the last couple of days working on a component that builds an RSS feed using Visual Source Safe data.  The purpose for the feed is two-fold.  First, the feed will be used by a nightly build to determine if anything has been updated since the previous build.  Second, the feed can be subscribed to by others on the development team, allowing them to keep up to date on the progress of the project. Over the next week or so, I'll be blogging more about the problems/issues/resolutions that I've run into.

The first element of the technique that I'm using has to do with identifying the VSS project that is to be used as the source for the feed.  Because it fits nicely with the VSS hierarchy (and because I thought it would be cool), we decided to include the VSS path in the URL.  For example, a URL of http://localhost/VSSRSS/top/second/third/rss.aspx would retrieve the history information for the project $/top/second/third.  To accomplish this, the RewritePath method associated with the HttpContext object is used.

So much for a description.  My reason for the post is not to describe the technique so much as to identify an error that I received and provide a solution that is not immediately obvious from the message.  While going through the development process, my first thought was to include the host information in the rewritten path.  Including the http:.  Why?  Beats me.  It was just the first thing that I did.  But when I did, a page with the following error appeared:

Invalid file name for monitoring: 'c:\inetpub\wwwroot\VSSRSS\http:'. File names for monitoring must have absolute paths, and no wildcards

This interesting error is actually caused by the inclusion of the protocol (the http) in the rewritten path.  The actual value of the path parameter should be relative to the current directory.  Which also implies that the rewritten path cannot be outside of the current virtual directory.

Hopefully this little tidbit will help some else down the road.