Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tomcat and custom error pages

2 views
Skip to first unread message

Darren Davison

unread,
May 6, 2002, 8:37:44 AM5/6/02
to

My webapp uses custom error pages defined in web.xml under Tomcat 4.01 for
code 404 and one or two others. The page is correctly served by Tomcat
when a resource is requested that doesn't exist - HOWEVER, Tomcat serves
the page with an HTTP status code of 200.

Have I not fully configured something, or is this a fault of Tomcat (or is
it not possible to serve custom error pages with the original error code
for some reason) ?

Any guidance appreciated.

--
darren@ public key
davison|uk.net www.davison.uk.net/key.jsp

"I declare myself 'King Dogbert', the first ruler of the internet"

Chris Smith

unread,
May 6, 2002, 8:58:34 AM5/6/02
to
Darren Davison wrote ...

>
> My webapp uses custom error pages defined in web.xml under Tomcat 4.01 for
> code 404 and one or two others. The page is correctly served by Tomcat
> when a resource is requested that doesn't exist - HOWEVER, Tomcat serves
> the page with an HTTP status code of 200.
>
> Have I not fully configured something, or is this a fault of Tomcat (or is
> it not possible to serve custom error pages with the original error code
> for some reason) ?

As far as I can tell, this is just an oddity of Tomcat. It causes even
more problems when the custom page you're trying to set is a 401 page...
the user never sees the authentication dialog, because Tomcat sends the
"access denied" page with a 200 response code. We had to take away our
custom "access denied" page and use the default auto-generated Tomcat
page to avoid the problem. Quite annoying.

Chris Smith

Jeff

unread,
May 30, 2002, 3:23:41 PM5/30/02
to
Chris Smith <cds...@twu.net> wrote in message news:<MPG.17402bea...@news.altopia.com>...

Has anyone figured this one out yet? I had to do the same thing for a
401 error - it sure is cheesy to use Tomcat's default 401 page...

Thanks,

Jeff

Ivan Morales

unread,
Aug 29, 2002, 2:51:13 PM8/29/02
to

We actually figured out a "hack" to fix the problem with "401
Unauthorized" codes using Basic authentication. In the web.xml file, add
the error-page tag the usual way:

<error-page>
<error-code>401</error-code>
<location>/notauthorized.jsp</location>
</error-page>

and in the notauthorized.jsp page add this at the beginning:

<%
response.setStatus(response.SC_UNAUTHORIZED);
response.setHeader("WWW-Authenticate", "BASIC realm=\"Your Realm\"");
%>

This will force the browser to display a login window and let users type
in their credentials. These two http headers are what Tomcat and other
servers use to challenge browsers to present credentials. Again this
only applies to Basic authentication since Form-based authentication
uses custom login and error pages.

--
Ivan Morales
Ned Davis Research

Chris Smith

unread,
Aug 29, 2002, 3:04:48 PM8/29/02
to
Ivan Morales wrote ...

> We actually figured out a "hack" to fix the problem with "401
> Unauthorized" codes using Basic authentication. In the web.xml file, add
> the error-page tag the usual way:
>
> <error-page>
> <error-code>401</error-code>
> <location>/notauthorized.jsp</location>
> </error-page>
>
> and in the notauthorized.jsp page add this at the beginning:
>
> <%
> response.setStatus(response.SC_UNAUTHORIZED);
> response.setHeader("WWW-Authenticate", "BASIC realm=\"Your Realm\"");
> %>

Great! Thanks for sharing. That should help considerably, and probably
ought to not cause problems even if this gets fixed.

Chris Smith

0 new messages