Return-Path: Delivered-To: apmail-hc-dev-archive@www.apache.org Received: (qmail 10028 invoked from network); 22 Sep 2009 15:55:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Sep 2009 15:55:12 -0000 Received: (qmail 38868 invoked by uid 500); 22 Sep 2009 15:55:12 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 38821 invoked by uid 500); 22 Sep 2009 15:55:12 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 38811 invoked by uid 99); 22 Sep 2009 15:55:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Sep 2009 15:55:11 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [92.42.190.144] (HELO ok2cons2.nine.ch) (92.42.190.144) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Sep 2009 15:55:02 +0000 Received: by ok2cons2.nine.ch (Postfix, from userid 1000) id E42C24BA437; Tue, 22 Sep 2009 17:54:41 +0200 (CEST) Date: Tue, 22 Sep 2009 17:54:41 +0200 From: Oleg Kalnichevski To: HttpComponents Project Subject: Re: Last redirect URL Message-ID: <20090922155441.GA29819@ok2cons2.nine.ch> References: <20090922094732.GA6650@ok2cons2.nine.ch> <25aac9fc0909220510h462b6597gdaf2575660fbd1ff@mail.gmail.com> <20090922125445.GB28443@ok2cons2.nine.ch> <25aac9fc0909220604i3d03920bybfa3db0e6d06d2cf@mail.gmail.com> <20090922131150.GA29793@ok2cons2.nine.ch> <25aac9fc0909220634t4cb99c78y4ab30cb70aca0d11@mail.gmail.com> <20090922135826.GA4585@ok2cons2.nine.ch> <25aac9fc0909220743u70654855u173128eadd378a8f@mail.gmail.com> <20090922145422.GA26493@ok2cons2.nine.ch> <19196d860909220823qb20075fs3aebe0a13e4e7df2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19196d860909220823qb20075fs3aebe0a13e4e7df2@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Checked: Checked by ClamAV on apache.org 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 wrote: > > > On Tue, Sep 22, 2009 at 03:43:18PM +0100, sebb wrote: > > > On 22/09/2009, Oleg Kalnichevski wrote: > > > > On Tue, Sep 22, 2009 at 02:34:55PM +0100, sebb wrote: > > > > > On 22/09/2009, Oleg Kalnichevski 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