Hi,
I used to see this when doing a response.sendRedirect() without following it
with a return(), but didn't see jsp source, just html source. I did have a
problem with mod_jk showing .jsp source when the URI contained a // in the
path like http://dom.ain/context//file.jsp, but that sounds like a different
problem and an upgrade of mod_jk fixed that.
The redirect without return was a common problem in dreamweaver ultradev 4.
response.sendRedirect() does not terminate execution of the servlet/jsp (nor
should it), it just adds header content to the output. I.E. is being 'nice'
by painting over the html of the page that sent the redirect with the html
of the redirected page, but netscape/mozilla leaves the html from the
redirecting page in the browser. A more serious issue is that if you are
using response.sendRedirect() to send an unauthorized user to a login page,
you are sending them the content you were trying to protect, and then
telling them they need to log in to see it. Not at all secure.
Though this is an overly simplistic analogy, think of a servlet/jsp as a
dynamically loaded function being called by tomcat. This is why you can't
call system.exit() in a servlet without terminating tomcat itself. Unless
you tell the servlet to cease processing, it will happily continue doing
what it does best -- outputting html.
bottom line:
if (not authorized) {
response.sendRedirect(some location);
return; // don't bother doing anything else
}
If you opened any jdbc connections be sure to close them before returning.
Sean
Web Solutions That Work Developing custom web solutions designed
specifically to accomplish the unique objectives of our clients. Phone
503-639-2727 Fax 503-639-0807
----- Original Message -----
From: Guy Rouillier [mailto:[EMAIL PROTECTED]
Sent: Monday, January 19, 2004 5:36 PM
To: Tomcat Users List
Subject: Mozilla showing JSP source code
[snip]
(4) The most reliable way to see this fail is via a redirect. This
happens most frequently on the secure half of our website (https). On
those pages, we have an authentication header at the top of each page:
<%@ include file="/includes/authenheader.jspf" %>
Inside this file, we check some session variables, and if they don't
have the right set of values (or those values don't exist) we
response.sendRedirect() to a login page. During this redirect, I
*always* see the source for the login page - the login page has not come
up cleanly one time. This page is very small, and neither the buffer or
timeout changes help.
If anyone has any ideas on how to address this problem, I'm willing to
try anything. I really am out of ideas and don't know where to go next.
Thanks for any help.
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
