I finally figured out the problem.  To find it I setup remote debugging on the server and then put break points on all the Redirect statements in the UrlRewriteModule.vb. The redirect that was causing the loop is on line 430. Working backwards I found that on line 416 the PortalAliasController.GetPortalAliasByTab would refuse to return an alias for the tab that was retrieved on line 199 using the TabController.GetTabByTabPath.  I discovered that the tab being returned by GetTabByTabPath was marked as deleted.   I queried the Tab in SQL Server and found that the TabPath was '//default'.  

Here is what it looked like in SQL:

TabID	PortalID	TabName	TabPath	IsDeleted
254	0	default	//default	1

Now it all made sense.  DNN was attempting to redirect to a deleted default page and got stuck in a redirect loop.  I simply deleted this row from the Tabs table and the redirect problem was resolved.    

It seems that PortalAliasController.GetPortalAliasByTab refusing to return a PortalAlias for deleted Tab is the correct behavior.  Should TabController.GetTabByTabPath return tabs that have been deleted?

I am not sure how I ended up having a deleted tab with a TabName of Default.  This site has been around since the DNN 3 days and upgraded along the way.  I tried to add a page with the name of "Default' and DNN 5.5 will not allow it, so that is good.   I was able to recreate the problem by adding a page.  Then deleted that page.  Then ran the following SQL update 'update tabs set TabPath = '//default',tabname='default' where tabid = 254' using the TabID of the page I just deleted.

---

Aaron Jackson

See unresolved bug post here: http://support.dotnetnuke.com/issue/V...

and here: http://support.dotnetnuke.com/issue/V...

For more information on the vast differences between databases from an upgrade versus a fresh install.  These inconsistencys are going to ultimately come back to haunt you, like it did me.