Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 99229 invoked from network); 18 Nov 2002 16:31:21 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Nov 2002 16:31:21 -0000 Received: (qmail 17288 invoked by uid 97); 18 Nov 2002 16:31:21 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 17168 invoked by uid 97); 18 Nov 2002 16:31:20 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 17044 invoked by uid 50); 18 Nov 2002 16:31:19 -0000 Date: 18 Nov 2002 16:31:19 -0000 Message-ID: <20021118163119.17034.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 13735] - Error code 302 in error-page XML tag prevents Authentication type FORM from working X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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: For additional commands, e-mail: