302/301 endless loop - just started happening

Topics: Developer Forum, User Forum
Oct 11, 2010 at 10:58 PM

site running Nopcommerce for many months, with iirf 2.0 and asp.net 4.0.  Worked fine, but just today started erroring due to IIS issuing a 302 to /default.aspx, but then iirf issues a 301 to redirect back to /, causing a infinite redirection error.... I can't figure out what caused this to start happening, as I can't see where IIS would ask to be redirected to /default.aspx (this should never happen right?) Any thoughts on this? Driving me crazy.



Oct 14, 2010 at 10:43 PM

You didn't say what version of IIS you are using.

Maybe this applies?: http://support.microsoft.com/kb/298408

When you say "this should never happen, right?", I think the answer is "Wrong."   It's possible to configure in IIS6 settings, without any third-party redirector like IIRF, a 302 redirection.  See here:


Also I think the default document sometimes gets delivered from IIS via a 302 response. 

Oct 14, 2010 at 10:48 PM

Cheeso, i should have added an update to this- I figured out the application I was running has URLRewriter built into it (which I knew) and it was configured to redirect any empy directory requests to a default.aspx. Not the way I want it to work (for seo reasons), but nonetheless was in there..

The part that blows my mind is, I didn't change the config on this site in probably 6 months, and then suddenly it started doing this 302/301 loop... so nothing changed on the server that would have caused this. WEIRD. anyway, it's been figured out and corrected now.


Oct 14, 2010 at 10:49 PM

But to reply to y our statement about IIS serving the default doc via a 302- I have never seen it done that way, as the whole purpose for the default document in IIS is to tell it what content to look for when requesting an empty dir. That's the part that confused me, as I initially suspected IIS was doing this.

Oct 14, 2010 at 10:53 PM

Glad you figured it out. 

About the 301/302 - I am not clear on exactly how IIS serves default documents, but I believe there are some cases in which IIS returns a 301 or 302 to do so.  I scanned a few blog posts trying to nail down just when this might be, but couldn't find a definitive answer.  So I gave up.  In any case it seems to be irrelevant to your situation, since you've fixed it, even though an explanation for the change in behavior is still missing.

Thanks for the reply.