Return-Path: Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@www.apache.org Received: (qmail 84662 invoked from network); 5 Nov 2003 21:10:44 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 5 Nov 2003 21:10:44 -0000 Received: (qmail 88374 invoked by uid 500); 5 Nov 2003 21:10:32 -0000 Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@jakarta.apache.org Received: (qmail 88357 invoked by uid 500); 5 Nov 2003 21:10:32 -0000 Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Commons HttpClient Project" Reply-To: "Commons HttpClient Project" Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 88340 invoked from network); 5 Nov 2003 21:10:32 -0000 Received: from unknown (HELO mail1.bluewin.ch) (195.186.1.74) by daedalus.apache.org with SMTP; 5 Nov 2003 21:10:32 -0000 Received: from localhost.localdomain (62.202.64.143) by mail1.bluewin.ch (Bluewin AG 7.0.020) id 3F8BF89700310415 for commons-httpclient-dev@jakarta.apache.org; Wed, 5 Nov 2003 21:10:37 +0000 Subject: Re: Redirect from one port to another From: Oleg Kalnichevski Reply-To: olegk@apache.org To: Commons HttpClient Project In-Reply-To: <3FA95AF9.3050900@limepeer.com> References: <3FA94A0F.5060202@limepeer.com> <1068061870.3234.47.camel@localhost.localdomain> <3FA95AF9.3050900@limepeer.com> Content-Type: text/plain Message-Id: <1068066509.3234.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 05 Nov 2003 22:08:30 +0100 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Sam, I would not bother reusing the method. The whole method recycling concept is kind of silly. It results in quite a bit of ugly code for virtually negligible performance gain. Also, I would always have HttpMethod#releaseConnection in a finally clause. As to the release of HttpClient 2.1, I would not expect the first alpha earlier than February next year, with the first beta coming by May. Oleg On Wed, 2003-11-05 at 21:18, Sam Berlin wrote: > I suppose that'll have to do. ;) > > Do you happen to notice anything obviously wrong with the following > workaround code? It is designed just to work with GetRequests, although > it theoretically should work with any request that does not contain > output data (such as a Post). Any ideas on when 2.1 will likely be > released as semi-stable? > > --- > > /** > * Executes the given HttpMethod in the HttpClient, following redirecits > * up to the specific number of times. > * This method is needed because HttpClient does not support redirects > * across protocols, hosts, and/or ports. > */ > public static void executeMethodRedirecting(HttpClient client, > HttpMethod methid, > int redirects) > throws IOException, HttpException { > for(int i = 0; i < redirects; i++) { > if(LOG.isInfoEnabled()) > LOG.info("Attempting connection (" + i + ") to " + > methid.getURI().getEscapedURI()); > client.executeMethod(methid); > switch(methid.getStatusCode()) { > case HttpStatus.SC_MOVED_TEMPORARILY: > case HttpStatus.SC_MOVED_PERMANENTLY: > case HttpStatus.SC_SEE_OTHER: > case HttpStatus.SC_TEMPORARY_REDIRECT: > if(!methid.getFollowRedirects()) { > if(LOG.isInfoEnabled()) > LOG.warn("Redirect requested but not supported"); > throw new HttpException("Redirect requested"); > } > > Header locationHeader = > methid.getResponseHeader("location"); > if(locationHeader == null) { > if(LOG.isInfoEnabled()) > LOG.warn("Redirect requested, no location header"); > throw new HttpException("Redirected without a > location"); > } > > String location = locationHeader.getValue(); > if(LOG.isInfoEnabled()) > LOG.info("Redirected requested to: " + > location); > URI newLocation = new URI(location.toCharArray()); > > // Retrieve the RequestHeaders > Header[] requestHeaders = methid.getRequestHeaders(); > > // Recycle this method so we can use it again. > methid.recycle(); > > HostConfiguration hc = methid.getHostConfiguration(); > hc.setHost( > newLocation.getHost(), > newLocation.getPort(), > newLocation.getScheme() > ); > > methid.setFollowRedirects(true); > > for(int j = 0; j < requestHeaders.length; j++) { > if(!requestHeaders[j].getName().equals("Host")) > methid.addRequestHeader(requestHeaders[j]); > } > > // Set up the new values for the method. > methid.setPath(newLocation.getEscapedPath()); > methid.setQueryString(newLocation.getEscapedQuery()); > methid.removeRequestHeader(HttpAuthenticator.WWW_AUTH_RESP); > // Release the existing connection... we know it is not > // the same host/port/protocol, because if it was, > // it would be handled internally by HttpClient. > methid.releaseConnection(); > // Loop around and try the method again. > break; > default: > return; > } > } > throw new HttpException("Maximum redirects encountered, bailing"); > } > > --- > > Thanks, > Sam > > > Oleg Kalnichevski wrote: > > >Sam, > >The architecture of HttpClient 2.0 is, let me say, well..., sub-optimal. > >The problem being that in HttpClient 2.0 redirects are handled by > >HttpMethodBase class, whereas connections are managed by HttpClient > >(through a HttpConnectionManager to be exact). As a result > >HttpMethodBase class has no means of obtaining a new connection when > >cross-sire redirect is requested. For various reasons (mainly due to the > >popular pressure from other projects reliant on HttpClient 2.0 API) the > >problem could not be solved for the 2.0 release. > > > >The bug is already fixed in CVS HEAD, but the code may still be > >unstable. 2.1 release will be free from this limitation. > > > >Cheers > > > >Oleg > > > >On Wed, 2003-11-05 at 20:05, Sam Berlin wrote: > > > > > >>Hi All, > >> > >>I'm curious why HttpClient is unable to redirect from one port to > >>another port. Does the HTTP spec disallow this, or does the internals > >>of HttpClient break if the redirect occurs? > >> > >>Thanks, > >> Sam > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org > >>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org > >> > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org > >For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org > > > > > >. > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org