New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...FriendlyURL functionality blocking our ReWrite rules from workingFriendlyURL functionality blocking our ReWrite rules from working
New Post
2/24/2015 11:21 PM

We are DNN novices and trying to set up a slightly complex arrangement of sites.  We have a core product built in one style of .Net web project, and a DNN 7.x site which uses another style of .Net project.  One is MVC and the other is Forms.  It seems the two cannot co-exist within the same IIS 'Site', and so we are pulling some tricks so they can appear to exist under one domain name, e.g.

Long story short: how can we tell the FriendlyURL handler to ignore some URL patterns and allow them to fall through to normal rewrite rules, without generating a 404 Not Found?

We want requests to to be handled first by the DNN site, with some Rewrite rules in place for 'forward' some requests to our core product site.  Lets say we have an endpoint in our core product that handles requests on /api/MakeSandwich.  A request to should be forwarded from the DNN site to the core product site.

 We have the two sites configured in IIS with the web.config for the DNN site containing:

    <friendlyUrl defaultProvider="DNNFriendlyUrl">
        <clear />
        <add name="DNNFriendlyUrl" type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, DotNetNuke.HttpModules" includePageName="true" regexMatch="[^a-zA-Z0-9 _-]" urlFormat="advanced" />

        <rule name="Rewrite to article.aspx">
          <match url="^api/(.*)" />
          <action type="Rewrite" url="{R:1}" />
        <rule name="response_location URL">
          <match serverVariable="RESPONSE_LOCATION" pattern="(.*)localhost:9000(.*)" />
          <action type="Rewrite" value="{R:1}{R:2}" />

 If we comment out the friendlyUrl section, the DNN site no longer has friendly Urls, but the rewrite works fine, is correctly forwarded.  If we put the friendlyUrl section back in, friendly URLs work fine, but we get 404 Not Found for /api/MakeSandwich.

According to the docs at and this 404 response is to be expected.  Anything that doesn't match the criteria specified, i.e. 1/ be a recognised DNN page or 2/ be a file found on the file system, will be treated as a 404 and returned, regardless of other config like rewrite rules that would have made the request succeed.

 Can we change the way the friendlyUrl module is acting?  Any advice greatly appreciated, we have been blocked by this for some time.


New Post
2/26/2015 12:16 PM
I'd recommend that you use advanced url management and configure it to ignore the various url's ( will help set that)

Buy the new Professional DNN7: Open Source .NET CMS Platform book Amazon US
New Post
3/10/2015 1:00 PM

Thank you Cathal!  I must say, we're wandering in the dark here.  I don't know how to add that module to a page, as its install instructions say.  Does this mean the UI it offers, for configuring the URL rewriter, needs adding to an Admin page as a module, rather like a block of content is added to a user facing page?  (I haven't done that either, we've been delivered a DNN site by a third party and are learning as we go).  We'll try this soon.

We have actually gone to extremes, and set up three independent sites within our IIS installation.  We created a single IIS site on port 80 with nothing but a few rewrite rules, which forward some requests to our coreproduct site, and the rest to a DNN site.  This has introduced a long series of drawbacks, because the DNN site frequently writes its HTTPAlias or PortalAlias into HTML it outputs, which is dnn.localhost in our case, so the rewriting site has to have some (probably horribly inefficient) outbound rewrite rules to alter dnn.localhost to our main domain name, so the HTML served to the browser contains the proper names.

This is a particular pain with editing pages, where the POST when saving an edit makes a POST to e.g.

and responds with something like:


To make the redirect done by the browser work, we must change dnn.localhost to our actual public domain name, but the magic number 38 in that response matches the number of characters in "http%3a%2f%2fdnn.localhost%2fSolutions", so using a rewrite rule to alter the domain name (which works fine) causes the javascript that parses the response to fail.  Our rewrite rule cannot do the extra calculation of counting string length and replacing the number 38, which is going to change depending on the URI of the page being edited.  This is extra annoying because the damn thing is separated by pipe characters, there's no need to encode the length of the string in the response.

Our solution to this is to make the internal domain name the same number of characters as the public domain name, i.e. something like 'foobar.arse' instead of '', and use an outbound rewrite rule to rewrite the response, leaving the magic number alone because it still represents the right number of characters.

All in all this rewrite module and its apparant lack of configuration documentation has been a huge pain.


New Post
3/12/2015 5:45 AM

We set up that advanced URL management UI module and it is a real breath of fresh air.  Why it isn't mentioned on the Advanced URL Management setup page baffles me.  We are now able to configure it to not act on certain URL patterns and allow web.config rewrite rules to take effect.

This has cost us a great deal of time, blood, sweat and tears, but it's great to see. Now we are facing problems getting 401 responses through from our backend site through DNN to the client, and I've posted a new thread on that subject.

Thanks for the advice!


New Post
3/12/2015 7:50 AM
thanks for the hint, I added a link to the page.

Cheers from Germany,
Sebastian Leupold

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
HomeHomeUsing DNN Platf...Using DNN Platf...Administration ...Administration ...FriendlyURL functionality blocking our ReWrite rules from workingFriendlyURL functionality blocking our ReWrite rules from working

These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out