You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/11/18 17:31:19 UTC
DO NOT REPLY [Bug 13735] -
Error code 302 in error-page XML tag prevents Authentication type FORM from working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13735>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13735
Error code 302 in error-page XML tag prevents Authentication type FORM from working
Brian.Ewins@btinternet.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From Brian.Ewins@btinternet.com 2002-11-18 16:31 -------
302 is not an 'error' as such - it is a temporary redirect, and is always sent
when you do a response.sendRedirect("blah") (which is what form based login does
internally). Is thus unsurprising that trying to catch 302s caused you a problem.
/All/ 1xx, 2xx, 3xx codes should be left well alone - they get interpreted by
the browser and don't show up as errors to the user. (For example - 304 results
in the page being served from the browser cache instead of from your server)
FYI, the codes which really /are/ errors worth handling are:
400, 401, 403, 404, 405, 411, 413, 415, 417, 500, 501, 503, 504
(theres more if you're using WebDAV, but even this set is excessive unless
you're proxying some requests)
Reading your comment '302 temporarily unavailable' it seems you may have
mistaken this for a 503 (Unavailable) code? See the servlet spec v2.3, section
2.3.3.2.
Hope this helps,
Baz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>