Post login, OK-200 returned instead of 302 redirect

[fijaicairo]

Hi all,
I'm having an odd intermittent problem with seam login. In a significant number of cases, rather than sending a 302 redirect to the browser after a login, the server sends an OK 200 status which results in the user being stuck at the login page.
All logs indicate that the login was actually successful behind the scenes though. The user can actually get to the parts of the application that required authentication if they navigate manually.

When a user puts in wrong credentials and are supposed to be redirected and shown the appropriate error message, they get the login page with no error message.

At the moment, the only way to clear this issue is to restart the server. We are using seam 2.0.1 GA on jboss 4.3 EAP.

[pmuir]

How are your navigation rules set up?

[fijaicairo]

Hi Pete,
Our navigation rules are fairly simple. Issue never occurred using default in JBoss 4.2.2 during development. In production, it typically clears up with a server restart.

<pages xmlns="http://jboss.com/products/seam/pages"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.0.xsd"
       no-conversation-view-id="/In/home_in.xhtml"
       login-view-id="/login.xhtml">

 <page view-id="*">
        <navigation>

            <rule if-outcome="USER_PROFILE">
                <redirect view-id="/In/user_profile.xhtml"/>
            </rule>
        ...
        </navigation>
 </page>

We also have a few page tags for specific view-ids some with login-required attributes. Another interesting fact is that we have multiple essentially identical login pages and this particular page seems to be the only exhibiting the problem.

[fijaicairo]

Maybe the issue only occurs under excessive load. At our daily peak, we process about 450 logins per minute so I guess thats bound to expose every fault there is.

[pmuir]

In the case you have shown Seam asks the Servlet API to do a redirect. We would need to know where the call goes wrong to debug further (which may be hard as you can't reliably reproduce currently).