RE: error-page status codes broken, no response to bugzilla report

[Donald Ball <db...@rhoworld.com>]

>The key issue is that declaring an <error-page> handler ***replaces*** the
>standard container behavior; it doesn't ***augment*** it.
>
>Consider, for example, a webapp that want to implement something like what
>the "Redirect" configuration parameter does for Apache (so that old URLs
>still work).  In today's world, you can write such a thing by mapping 404
>errors to a servlet that redirects to the desired resource (which
>ultimately returns a 200) for the URLs it knows about, and just returns
>the original 404 for everything else.
>
>With your proposed change, it would not be possible to implement this
>functionality.  That would be bad.

Sure it would be possible. You could handle that case by mapping /* to a
servlet and having it do the logic - map old URLs to new URLs (with a
proper 301, not a silent internal redirect and a 200, ideally), return 404s
for everything else. I can't say if it's easier or harder than the solution
you proposed, but it definitely looks possible.

For that matter - for the solution that you propose, by a strict reading of
the servlet spec, why wouldn't you get into an infinite loop if the
location for a 404 error-page returns a 404 status code? or bounce back and
forth between 404 and 301, say? I see that tomcat avoids the first problem,
at least, but I don't see where in the servlet spec it says that it's
supposed to...

>> Regardless of what you/we decide here for tomcat, should this be brought
>to
>> the servlet expert group for clarification in a forthcoming servlet
spec?
>
>You're certainly welcome to send them mail:
>
>  servletapi-feedback@eng.sun.com
>
>and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
>still subject to correction if needed.  (And I'm going to make the above
>argument if it's brought up for discussion -- to say nothing of the fact
>that this would break backwards compatibility for loads of existing
>applications ;-).

That's certainly something to consider. Since tomcat is the reference
implementation, ambiguities in the spec are resolved by looking at its
(buggy :)) behavior, yes? I guess I really wonder what webapps rely on this
behavior and why - it seems to me that fixing tomcat to work the way I
expect would fix more webapps than it would break. However, I guess I'd be
happy if the servlet spec simply explicitly declared what's supposed to
happen so web developers who care about http, rest, etc. realize they need
to explicitly give status codes to their pretty error pages. I'll write
something in.

Thanks for your patience with this pedantic problem.

- donald


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>