there could be a couple of reasons for these redirects. It's hard to guess, though, since we know nearly nothing about your environment (web server, network topology, etc.). For example, you might have implemented some HTTP / HTTPS rewrite rule that hides the session cookie from Apex. Your best option is to use a tool like Firebug and examine the HTTP requests and responses. Please feel free to post this information here, so we can help you diagnose the root cause.
This has also happened to one of our apps that has been imported to Apex 4.2 (fresh 4.2 installation with OHS on 10g DB)
Originally all was working fine but it seems to have only happened since we installed a patch #14784118 but that may be coincidence.
On IE9 the session id just incremement constantly with nothing showing for the app but on Chrome the error message below is given:
This web page has a redirect loop. The web page at http://.../f?p=101:2:13744390595646 has resulted in too many redirects.
I've reimported and the same thing happens so it isn't something in the app itself but something within the Apex environment that seems to have changed.
Edited by: user11315560 on 16-Nov-2012 02:07
Edited by: user11315560 on 16-Nov-2012 03:04
I've found this thread which details a patch we had applied that seems to be related to the problem.
We moved directly from APex 4.0 to 4.2 and would have probably encountered this issue in Apex 4.1 if we had gone to that as it changed the cookie format. The suggestion is on this thread
Apex 4.2 - Page sentry error
The solution there was to specify a short cookie name in the authentication scheme, instead of relying on the longer default cookie name. That might also help with your authentication scheme.
I have changed the Cookie name to C109 and the problem is now resolved.
Edited by: user11315560 on 16-Nov-2012 03:03
We just ran into this error on one of our applications after upgrading to 4.2 where we kept getting the same "redirect loop" error. The app used a No authentication (using DAD) authentication scheme. We allow HTTP access and the secure attribute under Session Cookie Attributes was set to Yes. Once we changed it to No the error went away. We're not sure if it was set different in 4.1 or if 4.2 just behaves different. This post got us in the ballpark so thought I'd pass this along in case some else encountered the save issue.