0

I'm attempting a simple redirect using this technique from the IIRF guide. My rules are:

ReWriteRule ^/endpage /highly/embedded/page.aspx [L]
RedirectRule ^/.*page\.aspx http://www.myurl.com/endpage [R=301]

I get a browser message saying "Firefox has detected that the server is redirecting the request for this address in a way that will never complete."

Any tips?

bobby
  • 29
  • 3

1 Answers1

0

What I would do is examine the IIRF log file, and see where the loop occurs.

Then modify the rules to ensure they terminate.

There can be unintended, unimagined loops. It should be easy to see from the log files.

Good luck.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
  • I outputted the log here: http://pastebin.com/P4tfeaLA But I can't really tell what I'm supposed to do. I thought the 'L' modifier would prevent looping, and the log does pick it up but I don't see it being discarded. Really appreciate your help! – bobby Oct 16 '12 at 10:35
  • Bobby - I looked at your pastebin. IIRF, by itself, appears to be doing the "right thing". It rewrites the /universalcredit url to the "long, embedded url", and redirects the long, embedded url to the short url. So, why are you seeing the loop? I'd guess that your ASPX code is generating a redirect, independently of IIRF. It is redirecting to the long embedded url, which IIRF then redirects to the short URL, which IIRF then rewrites to the long url, and then that ASPX redirects. Round and round we go. You could confirm this with Fiddler2. To fix, look in your ASPX code. – Cheeso Oct 16 '12 at 15:52
  • Hey Cheeso thanks for coming back to me. I tried your suggestion with two static HTML pages and get exactly the same loop. – bobby Oct 17 '12 at 09:53
  • There is another source of the unexpected redirect. To diagnose this I would get a client-side trace tool on the case - Fiddler2 is very good for this purpose. It will show you the redirects, which you can then correlate with the IIRF log. You should see one extra redirect in the client-side trace, which you then need to track down in some way. According to the log I saw, there is only one redirect being sent from IIRF. There is clearly another redirect; the source is unidentified but it's clearly there. – Cheeso Oct 19 '12 at 02:49
  • Thanks for replying Cheeso. Looks to me that the 'rewrite' rule is redirecting instead of rewriting: http://pastebin.com/BHrPNQqf – bobby Oct 19 '12 at 12:30
  • Bobby - the rewrite rule with `[R=301]` is redirecting. Should redirect. That's the intent. The other rule, with `[L]`, should *rewrite* only. And according to the IIRF log, that is what is happening. But obviously you are getting another redirect, from somewhere. It is possible that there is a browser cache or some other cache interfering, and it is using an "old" response that had a 301. Another possibility is IIRF config at another level (for example, server wide). Another possibility is a redirect configured into IIS itself. Something is doing it. IIRF claims to not be doing it. – Cheeso Oct 19 '12 at 20:59