Develop Reference

Localhost Redirected you too many times DotNetNuke

I have a DotNetNuke application I am trying to setup on localhost.
The application was working fine until I tried to change database connection. After reverting back the changes I made in conenctionStrings, I am getting error whenever I try to run it. The error is
The localhost page isn’t working
localhost redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS
Well, obiously I tried clearing cookies and also tried on multiple browsers but getting same result. Page is not working.
What can be the possible reason ?

Without seeing any source code the best answer I can give you is this, something in your code if forcing a redirect to iteself, which then forces another redirect to itself, etc.
It would basically by the same as doing this,
void DoSomething() {
// Infinite loop, activate!
DoSomething();
}
If you provide some source code or a link to it in the question I could give you a more detailed solution, but as the question stands this is the best I can do.

I had this issue a while ago, setting the trust level to full trust (in web.config) solved it for me.
Happy DNNing!
Michael

GET https://www.google-analytics.com/ga.js net::ERR_TIMED_OUT

When I'm Accessing my Site with Google Maps, The Maps load so slow and then this error Shows up. GET https://www.google-analytics.com/ga.js net::ERR_TIMED_OUT
Tried clearing my Cache and Browsing in Incognito Window but all show the same error
Tried in Other browser like Firefox but same error shows
Did someone encountered the same error before?
Please Help me , Thanks

I had this problem, solved by disabling the HTTPS Everywhere browser extension, which I believe is forcing the downloading of the ga.js through https from where it is not necessarily available.

This might be related to Firewall blocking google-analytics.com

URL Rewriting not working with URL ending ".ad" or ".cd"

I'm having some difficulties with my custom URL-rewriting setup. I'm not using any 3rd party tool to manage this, just using the global.asax by looking at every request and processing it.
The way I am using it is like:
www.mydomain.com/site/google.com
This page contains information about the site "google.com". I'm using the actual domain within the URL. This is all works fine.
I have simplified the code that I'm using just to show you an example of how it works:
Dim myContext As HttpContext = HttpContext.Current
Dim URL As String = myContext.Request.ServerVariables("URL")
If URL.ToLower.Contains("/site/") Then
URL = URL.Trim("/")
Dim strURL As String = URL.ToLower.Split("/")(1)
Redirect301("/site.aspx?url=" & strURL)
Exit Sub
End If
The issue I'm having is for certain domain extensions, the page will just load up custom 404 Not Found and I have no idea what the cause is.
Example of pages that don't load:
/site/google.ad
/site/google.cd
I'm guessing that the system thinks that .cd and .ad files are actual physical files and when it doesn't find them, it shows the custom 404 error. It doesn't actually looks like the request is getting through to the global.asax. When working in local environment, they actually load fine but only on the live server it has this issue and this is why it has been a nightmare trying to figure it out.
Another issue I found was loading the following URL:
/site/prn.com
This shows a 404 error again but this time not the custom one I created but the actual hard looking .net 404 error page. This also works fine in local environment.
There must be some IIS setting or code change I could do to try to get this resolved.
Thank you for your time :)
Aki

Check this link . Error message when you try to browse a Web page that is hosted on IIS 7.0: "HTTP Error 404.7 – FILE_EXTENSION_DENIED
This is the reason .ad .cd extensions are blocked.

How can I debug problems related to (lack of) postback

I have created a custom wizard control that dynamically loads usercontrols as you progress though it. The wizard is behaving as expected in all environments (PC/MAC) and browsers I have tested however a client is reporting that she is unable to complete the wizard. What I know about the issue:
It always fails on the same wizard step for this user (not the first step)
When the user clicks on the 'next' button in the step, the controller reports that the request was not a postback request (ie. IsPostBack() == false) and displays the first page of the wizard
The client is using a Mac and is accessing the site using the latest version of Safari
If the client switches to Firefox, or even just switches the user agent in Safari to something other than Safari the problem goes away.
So the problem is that when the client reaches a certain step in the wizard and clicks 'next', instead of re-loading that step to initiate the save event, the controller is merely displaying the first step of the wizard.
The step that fails contains many different form controls including textboxes, dropdowns, checkboxes and a fileupload control. We thought that it might have something to do with invalid characters getting pasted in from Word or something similar but that seems strange seeing as the problem only appears to be happening in Safari.
No exceptions are thrown and the windows event log is not displaying any related errors/warnings.
What I am looking for is ways to diagnose this error. At the moment I've been unable to reproduce the behavior that the client is experiencing but after going on site and seeing it for myself I can verify that it is definitely a valid issue.
Update 26/10/2010:
We installed a proxy on the clients NIC in order to retrieve the requests and responses. Problem is that when running the proxy the client appears to not have to problem any more. Does this behavior make sense to anyone?
Update 27/10/2010:
After investigating the traffic on the clients machine we noticed that the response headers were including some entries related to a client side proxy and we confirmed that they are in fact running the squid proxy in their office. To rule out that it had anything to do with the problem we got them to turn if off and then try the wizard again. This time no problems were encountered! So the proxy seems to be interfering with the requests causing .NET to somehow record the POST request as a non-postback. The following lines were found in the response header of a failed request. Can anyone comment on how squid could cause the behavior we are experiencing and what we can do about it?
Via:1.0 squid-12 (squid/3.1.0.13), 1.0 ClientSiteProxy:3128 (squid/2.7.STABLE4)
X-Cache:MISS from squid-12, MISS from ClientSiteProxy
X-Cache-Lookup:MISS from ClientSiteProxy:3128

If I have to troubleshoot this, I would first take a fiddler trace (www.fiddlertool.com) on the client and see what the requests are up to. I am not sure if Fiddler works on Mac, but any HTTP Watch, Network Monitor tool should be good. The reason that I am not doubting the code is that it works very well on all the other browsers, so the code shouldn't be bad.
May be there is something in the code [like adding cookies, etc] that is messing with the specific Client's browser.
HTH,
Rahul

For Mac There's a HTTPScoop which lets you to debug http post data's....it is similar to fiddler

The problem is not solved as such but we ended up just adding an exception to the clients squid proxy to bypass our website. The problem seems proxy/IIS/Safari related but we haven't been able to track the problem down any further and the client is happy with this solution as long as the problem doesn't resurface somewhere else. I'll re-post if more information surfaces.

POSTing to a re-written URL on IIS 6 doesn't work

I am working on a site which is programmed in C# .net. It uses a CMS called ADX Studio (a decision which predates my time there) which provides a shonky form of URL Rewriting (as far as I can tell it works by assigning an aspx page as the default 404 handler in IIS).
I have an web form which lives at a rewritten URL. I edited it so that the html form's action points back to the rewritten URL:
var u = new Uri(Request.RawUrl.Split(new char[1] { ';' }).Last());
userAdminForm.Action = u.PathAndQuery;
(kind of ugly but works based on what Request.RawUrl is on these rewritten URLs).
The "pretty" URL is something like this:
http://www.site.com/admin/user/edit/
On my development box (Windows XP/ IIS 5) when I initially tried POSTing back to URLs like this I got a HTTP 405 error. I worked around this by adding a script mapping so Aspnet_isapi.dll handles all (*) requests. And everything works fine on my development machine.
I just pushed my changes to the live server (Windows Server 2003 R2 and IIS 6) and the post fails silently. The page refreshes but all of my logic (from within an IsPostBack path in the code) doesn't get hit. No errors are displayed, it just doesn't work.
If I remove my code setting the .Action of the form then the postback works but it is posting to the ugly URL corresponding to the physical location of the aspx file rather than my page.
Am I missing a simple way to make this work? I don't want to be switching URL rewriting method or anything as this is a large legacy site and is unfortunately pretty dependent on ADX Studio so I don't want to do anything that will break that.
[edited because somehow the code above lost its code highlighting]

The issue is that the page's <form> tag is referencing the "ugly" url as the action. You can resolve that by completely removing the action tag from the form. Browsers will, by default, postback to the same page, ie. the "pretty" url.
This article explains how to accomplish an "actionless" form (~ two thirds of the way down) http://msdn.microsoft.com/en-us/library/ms972974.aspx

It seems like the problem is the same as it was on IIS 5. I can get it to work by doing the following in the IIS Manager:
Right click on the relevant website and select "Properties"
Choose the "Home Directory" tab
Click "Configuration" down in the "Application settings"
Click "Insert" next to the "Wildcard application maps"
Browse to the location of aspnet_isapi.dll (in my case: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll )
Untick "Check that file exists"
Click "OK" back through the Russian doll of dialogs.
This is basically the same as the approach that I linked to in the question for IIS5. However, it's not optimal because IIS is running every request through asp (even static files). Which seems like it can only slow things down. I'd like to be able to specify that asp only needs invoking for HTTP POST requests at least.
The weird thing is that IIS5 gave a HTTP 405 error when POSTing to an extension without a registered ISAPI extension but IIS6 just fails silently. And the page is being run through IIS (I can debug with a breakpoint in the Page_Load function) but IsPostBack (and IsCrossPagePostBack) don't get correctly set. Could it be related to the view state? Is there any alternative to my solution described above?

I've come to what I think is an optimal solution for this problem. It turns out that ADXStudio CMS does use the default 404 rule to do some form of URL rewriting. This has a problem with http POST:
when IIS initially executes a custom
URL on a 404 error, it changes POST to
GET, even if the client does a POST
request.
(thanks to elite brains' blog post about setting up IIS6 and ASP.NET MVC).
Rather than creating my own HttpModule I decided instead to use Ionics Isapi Rewrite Filter to rewrite my URLs. I then set the 404 error handler in IIS to the default. And I created this IIRF.ini file to redirect all requests to the same format as the 404 handler produced:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /Default.aspx?404;http://%{HTTP_HOST}$1 [U,L]
And everything seems to work great. The advantage over my previous answer is that the rewrite code is low level and runs fast and the -f and -d switches mean that if a file actually exists it isn't re-written and so static files don't have the overhead of running through .net.