On Tue, Sep 22, 2009 at 02:04:38PM +0100, sebb wrote: > On 22/09/2009, Oleg Kalnichevski <[email protected]> wrote: > > On Tue, Sep 22, 2009 at 01:10:38PM +0100, sebb wrote: > > > On 22/09/2009, Oleg Kalnichevski <[email protected]> wrote: > > > > On Mon, Sep 21, 2009 at 05:14:05PM -0700, Ken Krugler wrote: > > > > > > > > > > On Sep 21, 2009, at 2:30pm, droidin.net wrote: > > > > > > > > > >> > > > > >> I have rather simple HttpClient 4 code that calls HttpGet to get > > HTML > > > > >> output. > > > > >> The HTML returns with scripts and image locations all set to local > > > > >> (e.g. > > > > >> /images/foo.jpg ) so I need calling URL to make these into > > absolute ( > > > > >> http://foo.com/images/foo.jpg Now comes the problem - during the > > call > > > > >> there > > > > >> may be one or two 302 redirects so the original URL is no longer > > > > >> reflects > > > > >> the location of HTML. How do I get the latest URL of the returned > > > > >> content > > > > >> given all the redirects I may (or may not) have? > > > > >> > > > > >> I looked at HttpGet#getAllHeaders() and > > HttpResponse#getAllHeaders() - > > > > >> couldn't find anything. > > > > > > > > > > From past posts on the list, I thought httpMethod.getURI() would > > return > > > > > the final URL. > > > > > > > > > > -- Ken > > > > > > > > > > > > > > > > > > > > > > Ken, > > > > > > > > This is only partially correct. The original request object remains > > unmodified. > > > > > > This is a change from 3.1; perhaps needs a note in the Javadoc to say > > > it is not affected by redirects. > > > > > > > > > Sure. The question is where to put it. > > > > I was thinking of the Javadoc for getURI() in the interface > HttpUriRequest which is inherited by the implementing class(es). >
Which would be wrong in my opinion since this behavior is not defined by the interface but rather is implementation specific. So, DefaultRequestDirector would be a more appropriate place but not the most obvious one. So, I am leaning more towards adding a paragraph on HTTP request immutability to the tutorial, if it is not there already. Oleg > > > > > > So, one needs to retrieve the internal HttpUriRequest and HttpHost > > objects from > > > > the execution context in order to find out the final request URI / > > target host. > > > > For details see: > > > > > > > > > > http://hc.apache.org/httpcomponents-client/tutorial/html/fundamentals.html#d4e205 > > > > > > Note that the text talks about 'http.target_host' but the code uses: > > > > > > ExecutionContext.HTTP_TARGET_HOST > > > > > > which is presumably a constant for the value. I think this is confusing. > > > > > > I assume the HC4 code actually uses constants throughout, so would IMO > > > the document should do so too. > > > > > > Any objections to updating the documentation accordingly? > > > > > > > > > Certainly no objection from me, as long as the change is applied > > consistently > > across the entire tutorial. > > OK, I'll have a look at what is involved. > > Are you OK with dropping the constant values from the docs? > > > Oleg > > > > > > > I would prefer not to document the constant values (available via > > > Javadoc anyway), i.e. I propose to change: > > > > > > * 'http.target_host': HttpHost instance representing the connection > > target. > > > > > > to > > > > > > * ExecutionContext.HTTP_TARGET_HOST: HttpHost instance representing > > > the connection target. > > > > > > However, I suppose one could write: > > > > > > * ExecutionContext.HTTP_TARGET_HOST ('http.target_host'): HttpHost > > > instance representing the connection target. > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
