Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Delivered-To: moderator for tomcat-dev@jakarta.apache.org Received: (qmail 63815 invoked from network); 4 Mar 2001 08:07:46 -0000 Received: from dnvrpop3.dnvr.uswest.net (206.196.128.5) by h31.sny.collab.net with SMTP; 4 Mar 2001 08:07:46 -0000 Received: (qmail 10604 invoked by uid 0); 4 Mar 2001 08:07:54 -0000 Received: from unknown (HELO qwest.net) (63.229.231.153) by dnvrpop3.dnvr.uswest.net with SMTP; 4 Mar 2001 08:07:54 -0000 Date: Sun, 04 Mar 2001 01:07:14 -0700 Message-ID: <3AA1F7B2.6104B68E@qwest.net> From: "Stephen Jones" Sender: sjones To: tomcat-dev@jakarta.apache.org X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18pre21 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Bugzilla #484 not reproducible Content-Type: multipart/mixed; boundary="------------4C11F70B6C29B74DF8D7D027" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N --------------4C11F70B6C29B74DF8D7D027 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I was investigating bug #484 in Bugzilla: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=484 I was not able to recreate this bug as reported. I am using Tomcat 3.2.1 Final, where the bug was reported using Tomcat 3.2.1 Nightly on Jan 21, 2001. This may be the cause. I tested all of the cases mentioned, and added one more URL string to test: 4. "rtx/LoginFailed.html" I tested using SSL on both ports 443 and 445, with ajp12 and with ajp13. The main thing I learned is that you should never call response.sendRedirect() from a secure webapp without using ajp13, since it redirects to the URL but changes "https://" to "http://" and the desired redirect will not happen because the webserver is only allowing SSL connections. This is not a bug (since ajp13 works) but I bet a lot of people will make this mistake with their webapps. I am interpreting the documentation for response.sendRedirect() differently from the bug reporter; it does not specifically state that the path cannot extend outside the servlet context. Therefore, when scenarios a2 and a3 happen, the failure is warranted. I've attached a tarball of the webapp I used to test, which contains JSP pages to test all the permutations. I would like for at least one more person to verify this. In short, I think this is an ex-bug. Thanks, Steve --------------4C11F70B6C29B74DF8D7D027 Content-Type: application/x-gzip; name="484.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="484.tar.gz" H4sIACT3oToAA+2aXYubQBSGc2t+hSwsbKHEmXE+CrV7UbbQi5aWsDe9dKNpUrYxVUP/fucj rv2g2TbE0bjvQ8IQM6IwPmfOjIe/4NGkYwjhTAmhW4trJWt+u2OKCRILxZScEEoYl5NQdH1j hl1Vp2UYTsqiqA/1092WSx835Beuxz+lsy/Vtrtr6PEkkvO/j79gzfgLFVPdnzKuJiHp7pZa nvj4J5fToMyrbbGp8lmVb7J5nq3LfFFfXdyl5WxVf72/ePZyenk97ftOQRdY/1nf/set/yYW aP8Fh/8+OOB/hAAwfqz/cd/+q9Z/xa3/UsB/Hxzyf1kUiAEjx/h/13P+TwVt/OdSi2/nf/jv BeP/PP+2y6v6Zl1t03qxysugzMJXYekOzz7n9R89fl0d6BCSzdabxf0uy6/2pz0Pm7CCyDFg rP895/+0Xf9zRWPnP4X/Pjja/wgBYAxY/3vO/6mQrf/Mzf8S/nvheP9/Xx0gBpwjxv/FcPJ/ /SVu/x/+e+F0+f+yKL+nZQb1zwrr/3Dyf2HfBZj8n8B/H5ww/0cAOEOs/8PJ/wWRyuX/DP77 4MT5P2LAmWHX//tR7Ooaj/pP2vd/jNn5XwrU/3gheXv7/t31NEhef7j5pNsg+Th/Y9rgdrWu Qv15eDzMn5H7N4lc9yRyp0Psc8X4byJ5l9f4j/pPwVz9H6Go//RCM/5dzgGPxn/a1n8xbuI/ 49j/8cM/xP+fHw/MASPD1n/xvuu/HtZ/Kqb7+s8Y/vvgQP0Xyr+eAHb917P/1OSGjf/79z+o //bD0fs/eP07Cuz+75D859Lt/8J/L5zWf2z/AgAAAAAAAAAAAAAAwFD4AUjjymIAUAAA --------------4C11F70B6C29B74DF8D7D027--