DrewC wrote:
Ok, I guess I just needed to keep banging on this for another hour.  I am now
using a non-default context with the execute and then reconstructing the
final require URL with:

                HttpUriRequest finalRequest =
                    (HttpUriRequest) 
context.getAttribute(ExecutionContext.HTTP_REQUEST);
                HttpHost host = (HttpHost)
context.getAttribute(ExecutionContext.HTTP_TARGET_HOST);

                StringBuilder uriString = new StringBuilder();
                uriString.append(host.getSchemeName() + "://");
                uriString.append(host.getHostName());
                if (host.getPort() != -1) {
                        uriString.append(":" + host.getPort());
                }
                uriString.append(finalRequest.getURI().normalize().toString());

If anyone could confirm this is the right method, that would be appreciated.


Yes, it is. HttpClient does not mutate the content of the original request. Rather it creates a wrapper around it which does get changed in the course of the request execution. The only way to get hold of that object is by retrieving it from the execution context.

Another way of keeping track of all redirects is by providing a custom redirect handler.

Hope this helps

Oleg


Regards
Drew


DrewC wrote:
Hi, I am trying to do basically exactly what Magnus was attempting, to
access the final full URL to the resource after following redirects. But I have had no success attempting the techniques seen here,
though I admit to being a bit confused by them.  I have not had to deal
with the HttpContext previously and I am not exactly sure which
HttpGetMethod Olek suggests to cast.  But with my simplistic approach,
after the request is executed (with httpClient.execute(httpGet) and I have
confirmed several redirects already occured and were followed, the
  HttpGet.getURI
  (HttpUriRequest)httpGet).getURI()
  (HttpUriRequest)httpGet).getRequestLine().getUri()

all still retains the intial URL, not the final one.  I am using a shared
HttpClient (created via ThreadSafeClientConnManager), not sure if that
makes any difference. Any help appreciated.
Drew



olegk wrote:

On Sun, 2008-01-06 at 04:50 -0800, MaGGE wrote:
Hello,

I've just started using HttpClient for a little util I'm making. I'm
letting
it handle_redirects=true, but I need to process the URL it's been
redirected
to. How can I find the "current URL" after I've executed a request that
was
redirected?

I've tried a couple of things - which I feel is "wrong". First thing was
to
disable handle_redirects, and look for the "Location" header in a loop
of my
own. Challenge with this was that I could not see any way to replace the
URI
for the request object, so I'd have to make a new one - which is a
problem
because my method should be able to process any HttpUriRequest.

Second I tried to add a HttpRequestInterceptor to the client. But all I
can
get from the HttpRequest object given to the process method is the
RequestLine. That one only has the info found behind GET/POST etc, that
is
only the path and method. I'm still lacking the host, protocol and so
on.

I'm sure there's an easy way to do this that I've just missed ... Please
advice. :)

Thanks for your time,
Magnus
Hi Magnus

In addition to getting HttpHost out of the execution context, you may
also

(1) cast HttpRequest to HttpUriRequest in order to get the full request
URI

(2) extend or replace the default RedirectHandler with a custom one and
implement whatever redirect handling logic you deem appropriate

Hope this helps

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to