Bug? Weird redirect behavior

[gt...@dimon.is]

Hi all,

not sure if this bug is due to Cocoon or Tomcat or maybe to
Apache (which is delegating a virtual host to Tomcat which
handles it with Cocoon), but I'm getting really weird behavior
on http redirects. I have an XSP page that checks for a login
ID in the session, and if it doesn't find one, it redirects to a
login page using response.sendRedirect(), thus:

if(session.getValue("useruid") == null) {
    response.sendRedirect(response.encodeRedirectURL
("http://ddc.dimon.is/login.xml"));
}

This works whenever I test it, but I've been getting stray reports
from users elsewhere, who consistently get the following medley:

- part of this document (the _latter_ half!) as it would be served
  if the "useruid" value _were_ there, followed by
- the HTTP headers of the redirected request, followed by
- the result of the redirected request (the login.xml page).

The split in that extraneous first part occurs in an arbitrary-looking
location, in the middle of a tag, and the document is completed
right up to the </html> before the response to the redirected
request. The exact "source" given by Internet Explorer follows at
the end of this post. If you want to try for yourselves, the page is
located at http://ddc.dimon.is/ but note that I have been unable to
recreate the problem in-house.

Theories:
- Apache muddles up the two HTTP request-response pairs
  being handled, as it delegates them to Tomcat. Why?
- Cocoon has some sort of race condition where it manages to
  keep processing the XSP page and send the response, before
  the redirection occurs in another thread. Sounds far-fetched!)

Any ideas?

Thanks,

     - Gulli

Re: Bug? Weird redirect behavior

[Alex Muc <al...@utoronto.ca>]

I could be wrong, but I think you need to do something like the following:

if(session.getValue("useruid") == null) {
    response.sendRedirect(response.encodeRedirectURL
("http://ddc.dimon.is/login.xml"));
    return;
}

The only difference is the return statement which obviously stops the
processing of the rest of the page JSP/XSP/whatever.  I've had problems
similar to what you're describing and this usually does the trick for me,
but I'm not entirely sure your problem is the same that I was having.
Also, this has implications on your processing logic.

Hope it helps.
Alex.


gthb@dimon.is wrote:

> Hi all,
>
> not sure if this bug is due to Cocoon or Tomcat or maybe to
> Apache (which is delegating a virtual host to Tomcat which
> handles it with Cocoon), but I'm getting really weird behavior
> on http redirects. I have an XSP page that checks for a login
> ID in the session, and if it doesn't find one, it redirects to a
> login page using response.sendRedirect(), thus:
>
> if(session.getValue("useruid") == null) {
>     response.sendRedirect(response.encodeRedirectURL
> ("http://ddc.dimon.is/login.xml"));
> }
>
> This works whenever I test it, but I've been getting stray reports
> from users elsewhere, who consistently get the following medley:
>
> - part of this document (the _latter_ half!) as it would be served
>   if the "useruid" value _were_ there, followed by
> - the HTTP headers of the redirected request, followed by
> - the result of the redirected request (the login.xml page).
>
> The split in that extraneous first part occurs in an arbitrary-looking
> location, in the middle of a tag, and the document is completed
> right up to the </html> before the response to the redirected
> request. The exact "source" given by Internet Explorer follows at
> the end of this post. If you want to try for yourselves, the page is
> located at http://ddc.dimon.is/ but note that I have been unable to
> recreate the problem in-house.
>
> Theories:
> - Apache muddles up the two HTTP request-response pairs
>   being handled, as it delegates them to Tomcat. Why?
> - Cocoon has some sort of race condition where it manages to
>   keep processing the XSP page and send the response, before
>   the redirection occurs in another thread. Sounds far-fetched!)
>
> Any ideas?
>
> Thanks,
>
>      - Gulli