Re: urlMappings interaction with web.config hierarchy

• From: Luke Dalessandro <usenet@xxxxxxxxx>
• Date: Fri, 13 Jan 2006 14:45:42 GMT

Luke Dalessandro wrote:

I have an application with the following layout

    /root/
    /root/Default.aspx
    /root/web.config
    /root/child/
    /root/child/web.config

web.config has a custom configuration section "testSection" with the basic layout of:

    <testSection>
        <tests>
           <add id="" value="" />
        </tests>
    </testSection>

The root web.config defines:

    <testSection>
        <tests>
           <add id="test1" value="root1" />
           <add id="test2" value="root2" />
        </tests>
    </testSection>

the child web.config defines:

    <testSection>
        <tests>
          <remove id="test2" />
          <add id="test2" value="child2" />
          <add id="test3" value="child3" />
        </tests>
    </testSection>

finally, the root web.config defines the url mapping:

    <urlMappings enabled="true">
        <add url="~/root/child/Default.aspx"
        mappedUrl="~/root/Default.aspx"/>
    </urlMappings>

Essentially, my goal is, for the url "~/root/child/Default.aspx", I want to run the file "~/root/Default.aspx" BUT, I want it run as if were located at "~/root/child/Default.aspx", inheriting the child defined web.config.

Can someone point me towards the solution? As it is now, the page gets run as if it were located where it is actually located, and no web.config accumulation is done. Presumably I either need a way to manually load configuration files before the Rewrite happens, or I need a way to execute a .aspx class as if it were located at a different location. I imagine that the first way is the better way to go, as everything else (urls etc) should be processed as if the file were executing at it's actual location.

I just need a starting point. I have written custom url mapping modules, but nothing I know how to do will allow me to solve my problem.

Thanks in advance,
Luke

Ok,

An update for anyone who cares. I've got this working by using a custom IHttpHandler. Essentially, I check all incoming requests for existence. If they exist, I process them normally.

If they don't exist, and a "searchParent" flag is set in the configuration file for the current execution directory, I strip the last directory from the url, and check for existence. This runs recursively until I find the file, I hit the application root directory, or I hit a directory where parent searching isn't enabled.

Just as an aside, to load a web configuration file from a directory that's not the currently execution directory, use the GetSection(string, string) version of GetSection, passing the path to the file as the second parameter. This is necessary because I'm never actually Rewriting the context url, I'm just doing a directory search.

The magic that happens is that, in the IHttpHandler, the method that I am using to execute the page is PageParser.GetCompiledPageInstance. This takes three parameters, the first two specify the page to run, and the third is the context to run in.

By loading the page that I've found, with the context that still lists the current execution path, the page loads as if it were at the requested location. Essentially, this is sort of a url rewrite without changing the context.

Caveats:

    I'm not sure if this causes POST problems, or cache strangeness.
    I'm still looking into it.

    I've found that if I have an actual url rewriting module that
    runs before I run this execution file search, I need to pass
    "false" as the second parameter to context.RewritePath() or Urls
    are not resolved correctly by the page. I'm not sure if this is
    a RewritePath problem or specific to instantiating a page that
    doesn't actually reside where the context thinks it does.

    VirtualPathProvider seems to offer customization potential, but
    I haven't been able to figure it out yet.

I'll post any more issues I run into for anyone paying attention. Hope this helps if you're trying to do something like this.

Luke

Update:

Thanks,
Luke
.

• References:
  • urlMappings interaction with web.config hierarchy
    • From: Luke Dalessandro
  • Re: urlMappings interaction with web.config hierarchy
    • From: Luke Dalessandro

• Prev by Date: Re: Asp.net 2.0 caching and images
• Next by Date: Re: File Download
• Previous by thread: Re: urlMappings interaction with web.config hierarchy
• Next by thread: mssql export to webhost, when creating asp.net pages
• Index(es):
  • Date
  • Thread

• Windows
• Science
• Usenet

• Archive
• About
• Privacy
• Search
• Imprint