Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 22338 invoked from network); 18 Nov 2002 16:52:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Nov 2002 16:52:37 -0000 Received: (qmail 4548 invoked by uid 97); 18 Nov 2002 16:53:34 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 4524 invoked by uid 97); 18 Nov 2002 16:53:33 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 4503 invoked by uid 50); 18 Nov 2002 16:53:33 -0000 Date: 18 Nov 2002 16:53:33 -0000 Message-ID: <20021118165333.4502.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 14643] New: - duplicate code for redirection 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=14643 duplicate code for redirection Summary: duplicate code for redirection Product: Commons Version: 2.0 Milestone 1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: HttpClient AssignedTo: commons-dev@jakarta.apache.org ReportedBy: joerg.heinicke@gmx.de Hello, I have encountered some strange things according following redirects. Since a few days a log message has been added: "(HttpMethodBase.java:882) - Redirect requested but followRedirects is disabled" For me this message is really strange, because every server side redirection works and I get the expected result at the client. Only the test for the start page (It's a XUL application and we test server side, whether it's a Mozilla browser or not.) failed. I found out that this is because of the lost header information when follow redirects is set to false. So the useragent is reset to "Jakarta Commons-HttpClient/2.0M1". For me this seems to be a bit buggy. In HttpMethodBase.processRedirectResponse() it is asked for getFollowRedirects(), but not at HttpMultiClient.executeMethod(): (starts at line 323) if (status == HttpStatus.SC_MOVED_PERMANENTLY || status == HttpStatus.SC_MOVED_TEMPORARILY || status == HttpStatus.SC_SEE_OTHER || status == HttpStatus.SC_TEMPORARY_REDIRECT) { /* header "location" handling snipped */ return executeMethod(method); <<========= } executeMethod() is processed recursively. Can somebody have a look on it? It's not so important, because you can explicitely set followRedirects to true and everything works ok. But when it's not set (=> default = false), redirects shell not be followed. -- To unsubscribe, e-mail: For additional commands, e-mail: