Re: Last redirect URL

[sebb-2-2]

On 22/09/2009, Oleg Kalnichevski <olegk@...> 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.

>  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?

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Tue, Sep 22, 2009 at 01:10:38PM +0100, sebb wrote:

> On 22/09/2009, Oleg Kalnichevski <olegk@...> 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.

> >  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.

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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:

> On Tue, Sep 22, 2009 at 01:10:38PM +0100, sebb wrote:
>  > On 22/09/2009, Oleg Kalnichevski <olegk@...> 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).

>
>  > >  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: dev-unsubscribe@...
>  > For additional commands, e-mail: dev-help@...
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Tue, Sep 22, 2009 at 02:04:38PM +0100, sebb wrote:

> On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > On Tue, Sep 22, 2009 at 01:10:38PM +0100, sebb wrote:
> >  > On 22/09/2009, Oleg Kalnichevski <olegk@...> 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: dev-unsubscribe@...
> >  > For additional commands, e-mail: dev-help@...
> >  >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: dev-unsubscribe@...
> >  For additional commands, e-mail: dev-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:

> On Tue, Sep 22, 2009 at 02:04:38PM +0100, sebb wrote:
>  > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
>  > > On Tue, Sep 22, 2009 at 01:10:38PM +0100, sebb wrote:
>  > >  > On 22/09/2009, Oleg Kalnichevski <olegk@...> 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.

I've already updated getURI() - best treat that as a temporary experiment ...

If that text is OK, it can be moved elsewhere, but given that the
httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think that
there needs to be a pointer from there as well.

Does getURI() behaviour vary between implementations?
If so, this should definitely be mentioned in the interface Javadoc.

Or is it just that the implementations may handle redirect URIs differently?

>
>  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: dev-unsubscribe@...
>  > >  > For additional commands, e-mail: dev-help@...
>  > >  >
>  > >
>  > >  ---------------------------------------------------------------------
>  > >  To unsubscribe, e-mail: dev-unsubscribe@...
>  > >  For additional commands, e-mail: dev-help@...
>  > >
>  > >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@...
>  > For additional commands, e-mail: dev-help@...
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:

> On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> >
> > 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.
>
> I've already updated getURI() - best treat that as a temporary experiment ...
>
> If that text is OK, it can be moved elsewhere, but given that the
> httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think that
> there needs to be a pointer from there as well.
>
> Does getURI() behaviour vary between implementations?
> If so, this should definitely be mentioned in the interface Javadoc.
>

Yes, it does, like that of many other methods. In some implementations the
request URI remains immutable, in others it can be changed. I certainly see
nothing that makes getURI() method so special.

> Or is it just that the implementations may handle redirect URIs differently?
>

I thought the whole point of having an interface was to allow for
implementations with different behavior.

> >
> >  So, I am leaning more towards adding a paragraph on HTTP request immutability
> >  to the tutorial, if it is not there already.
> >
> >  Oleg
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:

> On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:
>  > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
>  > >
>
> > > 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.
>  >
>  > I've already updated getURI() - best treat that as a temporary experiment ...
>  >
>  > If that text is OK, it can be moved elsewhere, but given that the
>  > httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think that
>  > there needs to be a pointer from there as well.
>  >
>  > Does getURI() behaviour vary between implementations?
>  > If so, this should definitely be mentioned in the interface Javadoc.
>  >
>
>
> Yes, it does, like that of many other methods. In some implementations the
>  request URI remains immutable, in others it can be changed. I certainly see
>  nothing that makes getURI() method so special.
>
>
>  > Or is it just that the implementations may handle redirect URIs differently?
>  >
>
>
> I thought the whole point of having an interface was to allow for
>  implementations with different behavior.
>

But the Javadoc needs to be clear what the contract for the method is.
IMO at present this is not clear.
This is especially true since it is a change from the behaviour in 3.1
(which is where we started).

>  > >
>  > >  So, I am leaning more towards adding a paragraph on HTTP request immutability
>  > >  to the tutorial, if it is not there already.
>  > >
>  > >  Oleg
>  > >
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[olegk]

On Tue, Sep 22, 2009 at 03:43:18PM +0100, sebb wrote:

> On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:
> >  > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> >  > >
> >
> > > > 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.
> >  >
> >  > I've already updated getURI() - best treat that as a temporary experiment ...
> >  >
> >  > If that text is OK, it can be moved elsewhere, but given that the
> >  > httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think that
> >  > there needs to be a pointer from there as well.
> >  >
> >  > Does getURI() behaviour vary between implementations?
> >  > If so, this should definitely be mentioned in the interface Javadoc.
> >  >
> >
> >
> > Yes, it does, like that of many other methods. In some implementations the
> >  request URI remains immutable, in others it can be changed. I certainly see
> >  nothing that makes getURI() method so special.
> >
> >
> >  > Or is it just that the implementations may handle redirect URIs differently?
> >  >
> >
> >
> > I thought the whole point of having an interface was to allow for
> >  implementations with different behavior.
> >
>
> But the Javadoc needs to be clear what the contract for the method is.
> IMO at present this is not clear.
> This is especially true since it is a change from the behaviour in 3.1
> (which is where we started).
>

I think the contract of HttpUriRequest#getURI() is crystal clear: it returns
request URI of the request object. Whether or not that property may change in
the course of request execution depends on a particular implementation and
ought not to be imposed by the interface itself.

Given the fact that 3.1 did not support HTTP _request_ object as a concept, I
_personally_, do not think this method deserves a special treatment.

Oleg

> >  > >
> >  > >  So, I am leaning more towards adding a paragraph on HTTP request immutability
> >  > >  to the tutorial, if it is not there already.
> >  > >
> >  > >  Oleg
> >  > >
> >
> >
> > ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: dev-unsubscribe@...
> >  For additional commands, e-mail: dev-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sam Berlin]

I'm inclined to agree with sebb that the contract of the interface should
specify what this URI refers to.  In cases where the programmer isn't aware
of the implementation (ie, they are passed the object as an interface and
expected to use it as such), they should be aware what kind of return value
they will receive.  While I agree with Oleg that implementations should be
free to change, I'm of the opinion that the thing that changes is the means
of implementation, not the definition for what it returns.

Adding something as innocuous as, "Implementations are encouraged to return
the URI that was initially requested.  If the programmer wants to know the
URI of any redirected locations, see [a tutorial]."

Sam

On Tue, Sep 22, 2009 at 10:54 AM, Oleg Kalnichevski <olegk@...>wrote:

> On Tue, Sep 22, 2009 at 03:43:18PM +0100, sebb wrote:
> > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > > On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:
> > >  > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > >  > >
> > >
> > > > > 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.
> > >  >
> > >  > I've already updated getURI() - best treat that as a temporary
> experiment ...
> > >  >
> > >  > If that text is OK, it can be moved elsewhere, but given that the
> > >  > httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think
> that
> > >  > there needs to be a pointer from there as well.
> > >  >
> > >  > Does getURI() behaviour vary between implementations?
> > >  > If so, this should definitely be mentioned in the interface Javadoc.
> > >  >
> > >
> > >
> > > Yes, it does, like that of many other methods. In some implementations
> the
> > >  request URI remains immutable, in others it can be changed. I
> certainly see
> > >  nothing that makes getURI() method so special.
> > >
> > >
> > >  > Or is it just that the implementations may handle redirect URIs
> differently?
> > >  >
> > >
> > >
> > > I thought the whole point of having an interface was to allow for
> > >  implementations with different behavior.
> > >
> >
> > But the Javadoc needs to be clear what the contract for the method is.
> > IMO at present this is not clear.
> > This is especially true since it is a change from the behaviour in 3.1
> > (which is where we started).
> >
>
> I think the contract of HttpUriRequest#getURI() is crystal clear: it
> returns
> request URI of the request object. Whether or not that property may change
> in
> the course of request execution depends on a particular implementation and
> ought not to be imposed by the interface itself.
>
> Given the fact that 3.1 did not support HTTP _request_ object as a concept,
> I
> _personally_, do not think this method deserves a special treatment.
>
> Oleg
>
> > >  > >
> > >  > >  So, I am leaning more towards adding a paragraph on HTTP request
> immutability
> > >  > >  to the tutorial, if it is not there already.
> > >  > >
> > >  > >  Oleg
> > >  > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > >  To unsubscribe, e-mail: dev-unsubscribe@...
> > >  For additional commands, e-mail: dev-help@...
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[olegk]

On Tue, Sep 22, 2009 at 11:23:22AM -0400, Sam Berlin wrote:

> I'm inclined to agree with sebb that the contract of the interface should
> specify what this URI refers to.  In cases where the programmer isn't aware
> of the implementation (ie, they are passed the object as an interface and
> expected to use it as such), they should be aware what kind of return value
> they will receive.  While I agree with Oleg that implementations should be
> free to change, I'm of the opinion that the thing that changes is the means
> of implementation, not the definition for what it returns.
>
> Adding something as innocuous as, "Implementations are encouraged to return
> the URI that was initially requested.  If the programmer wants to know the
> URI of any redirected locations, see [a tutorial]."
>
> Sam
>

Sam, Sebastian,

I took my best shot at writing the javadocs and the tutorial for HttpClient. If
some areas are not clear enough, do feel free to just go ahead and make changes
you deem necessary. There are always different ways of looking at things.

Oleg

> On Tue, Sep 22, 2009 at 10:54 AM, Oleg Kalnichevski <olegk@...>wrote:
>
> > On Tue, Sep 22, 2009 at 03:43:18PM +0100, sebb wrote:
> > > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > > > On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:
> > > >  > On 22/09/2009, Oleg Kalnichevski <olegk@...> wrote:
> > > >  > >
> > > >
> > > > > > 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.
> > > >  >
> > > >  > I've already updated getURI() - best treat that as a temporary
> > experiment ...
> > > >  >
> > > >  > If that text is OK, it can be moved elsewhere, but given that the
> > > >  > httpMethod#getURI() Javadoc leads back to HttpUriRequest, I think
> > that
> > > >  > there needs to be a pointer from there as well.
> > > >  >
> > > >  > Does getURI() behaviour vary between implementations?
> > > >  > If so, this should definitely be mentioned in the interface Javadoc.
> > > >  >
> > > >
> > > >
> > > > Yes, it does, like that of many other methods. In some implementations
> > the
> > > >  request URI remains immutable, in others it can be changed. I
> > certainly see
> > > >  nothing that makes getURI() method so special.
> > > >
> > > >
> > > >  > Or is it just that the implementations may handle redirect URIs
> > differently?
> > > >  >
> > > >
> > > >
> > > > I thought the whole point of having an interface was to allow for
> > > >  implementations with different behavior.
> > > >
> > >
> > > But the Javadoc needs to be clear what the contract for the method is.
> > > IMO at present this is not clear.
> > > This is especially true since it is a change from the behaviour in 3.1
> > > (which is where we started).
> > >
> >
> > I think the contract of HttpUriRequest#getURI() is crystal clear: it
> > returns
> > request URI of the request object. Whether or not that property may change
> > in
> > the course of request execution depends on a particular implementation and
> > ought not to be imposed by the interface itself.
> >
> > Given the fact that 3.1 did not support HTTP _request_ object as a concept,
> > I
> > _personally_, do not think this method deserves a special treatment.
> >
> > Oleg
> >
> > > >  > >
> > > >  > >  So, I am leaning more towards adding a paragraph on HTTP request
> > immutability
> > > >  > >  to the tutorial, if it is not there already.
> > > >  > >
> > > >  > >  Oleg
> > > >  > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > >  To unsubscribe, e-mail: dev-unsubscribe@...
> > > >  For additional commands, e-mail: dev-help@...
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...