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.

Comments

  • bruce January 18, 2004 7:35 PM

    This little tidbit did help someone down the road. This is exactly what I am doing wrong. Thanks for the information. The power of Google and Blogs at work again.

  • bruce February 25, 2004 4:01 AM

    Wonderful -- helped me out with a problem of my own!

  • bruce April 22, 2004 11:57 AM

    spot on - have just upgraded to .NET 1.1 and this overlooked bug came up. Looks like 1.0 could handle a physical path with forward slashes: F:/dir/dir/dir/ but 1.1 is (rightly) a bit more pedantic.

  • bruce May 11, 2004 3:53 PM

    Thank God. Now I don't have to fire my I.T. guy. (xo)

  • bruce May 11, 2004 8:56 PM

    This was super helpful, couple things I figured out: use HttpRequest.RawUrl this gives everything after the hostname/, super convenient, however leads to that other problem how to solve the path issue since any relative items in your response are expected to come from the original path. I build a mechanism to generate my pages using explicit paths by passing the authority and Url.Segments into the routine for generating the pages. Anyways, thanks for the heads up.

  • bruce June 17, 2004 12:46 AM

    Thanks for your post. I ran into this problem this evening and found this nasty error myself. Ironically, I was also creating an RSS reader using a similar technique.

  • bruce February 8, 2005 3:49 PM

    Thanks for the post! I came to the same conclusion. It works fine with relative paths. Now I just have to figure out how to get the directories to go forward and backward depending how deep into folders I am. IE...
    folder1/folder2/folder3/page.aspx

    The path would have to be ../../../page-I-want to-be-at.aspx

    So I just need to find away to find out how far I am away from the root directory and adjust the path accordingly.

    Thanks!!

  • bruce August 8, 2005 6:07 PM

    Hi Bebandit,

    I'm having the same question. Did you find a solution for your problem.

    In my situation the 'directory-level' is variable ie:

    sometimes:

    folder1/folder2/folder3/folder4

    or

    folder1/folder2/folder3

    but in both situations the path must be set to
    folder4/default.aspx

  • bruce September 29, 2005 3:04 AM

    My problem not yet solved. But it gave me somewhat idea to understand the problem

  • bruce June 8, 2006 9:44 AM

    Is there anyway to rewrite the url and include the "http:" portion of the path?

  • bruce June 8, 2006 9:56 AM

    Not so far as I know. And it's too late for a change from http to https to have any impact. The request has already arrived at the server in an unencrypted form and RewritePath isn't used to change the destination domain.

  • bruce June 8, 2006 10:59 AM

    Is there any other method that is similar to rewritepath that would allow me to include the http portion of the path?

  • bruce June 8, 2006 11:00 AM

    i know that there is the redirect method, but i need to be able to have the functionality of rewritepath with the ability to include the protocol.

  • bruce June 8, 2006 11:06 AM

    Why are you trying to include the protocol?

  • bruce June 8, 2006 11:32 AM

    Basically, I am trying to include http for nonsecure pages and https for secure pages. I have seen numerous posts about modules that can be developed to do just this, but we already have a module for handling http requests so I wanted a way to do this without having to rewrite too much code.

  • bruce June 8, 2006 12:35 PM

    The problem is that setting the protocol to https while rewriting the URL doesn't change anything. It doesn't indicate that the page is being viewed over SSL. Which is probably why you can't do it. In fact, changing the protocol at this point has no impact on how the request is processed.

Leave a Comment

(required) 
(optional)
(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS