hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Last redirect URL
Date Tue, 22 Sep 2009 15:54:41 GMT
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@apache.org>wrote:
> 
> > On Tue, Sep 22, 2009 at 03:43:18PM +0100, sebb wrote:
> > > On 22/09/2009, Oleg Kalnichevski <olegk@apache.org> wrote:
> > > > On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote:
> > > >  > On 22/09/2009, Oleg Kalnichevski <olegk@apache.org> 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@hc.apache.org
> > > >  For additional commands, e-mail: dev-help@hc.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >

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


Mime
View raw message