Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C05ADD14F for ; Wed, 4 Jul 2012 09:19:22 +0000 (UTC) Received: (qmail 85221 invoked by uid 500); 4 Jul 2012 09:19:22 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 85067 invoked by uid 500); 4 Jul 2012 09:19:21 -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 85045 invoked by uid 99); 4 Jul 2012 09:19:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 09:19:21 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [217.150.250.48] (HELO kalnich.nine.ch) (217.150.250.48) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Jul 2012 09:19:11 +0000 Received: from [192.168.42.9] (unknown [213.55.184.252]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by kalnich.nine.ch (Postfix) with ESMTPSA id 18A88B801E1 for ; Wed, 4 Jul 2012 11:18:52 +0200 (CEST) Message-ID: <1341393528.5804.21.camel@ubuntu> Subject: Re: URIBuilder setQuery() method inconsistent with other set methods From: Oleg Kalnichevski To: HttpComponents Project Date: Wed, 04 Jul 2012 11:18:48 +0200 In-Reply-To: References: <1340714618.5475.24.camel@ubuntu> <1341327898.5804.18.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 On Tue, 2012-07-03 at 16:39 +0100, sebb wrote: > On 3 July 2012 16:04, Oleg Kalnichevski wrote: > > On Tue, 2012-06-26 at 17:55 +0100, sebb wrote: > >> On 26 June 2012 14:33, sebb wrote: > >> > On 26 June 2012 13:43, Oleg Kalnichevski wrote: > >> >> On Tue, 2012-06-26 at 12:13 +0100, sebb wrote: > >> >>> The setQuery(String) method currently expects an escaped, ASCII-only > >> >>> string - basically encoded form data - whereas all the other set > >> >>> methods expect unescaped input. > >> >>> This is a bit confusing. > >> >>> > >> >> > >> >> Yes, I am aware of it. I was going to deprecate this method in 4.3 and > >> >> replace it with something like #parseQuery. > >> >> > >> >>> AFAIK, a query string does not have to consist of name value pairs > >> >>> (i.e. form data), it can be any arbitrary string. > >> >>> There's currently no way for the end-user to provide such a query. > >> >>> They would have to use the URI class. > >> >> > >> >> In this case it is basically a lone parameter without a value. > >> > > >> > Yes and no; depends what is allowed for a parameter name. > >> > >> The URI class allows spaces in the query segment. > >> AFAICT this is currently impossible to replicate using URIBuilder, > >> because it converts space to '+'. > >> > >> > Also, '+' only means space in the context of form data; otherwise it > >> > is just another safe character in the query. > >> > > >> > Presumably applications that use arbitrary query strings decode the > >> > query differently from ones that expect form data. > >> > > >> >>> Maybe that is OK, in which case we just need to clarify the URIBuilder > >> >>> Javadoc to state that it is only intended for use with form data > >> >>> queries. > >> >>> > >> >>> Perhaps there should be a setQuery(NVP) method which handles form data directly? > >> >>> > >> >> > >> >> Makes sense. The question is whether we should add this method in 4.2.1 > >> >> or wait until 4.3. > >> > > >> > It could wait. > >> > > >> > As could providing support for non-form data query strings; the URI > >> > class can be used meanwhile. > >> > > > > Sebastian > > > > I deprecated #setQuery method and added new method to set arbitrary > > custom query component. Please review. > > > > http://svn.apache.org/viewvc?rev=1356775&view=rev > > Mostly OK. > > I'm not quite sure why query and queryParams are both used to build > the same URI query > [Equally, why setCustomQuery does not set queryParams=null.] > > Is there a use case that requires both a custom query and query params? > If so, then there should be a test case for it. > URI uri = new URIBuilder() .setCustomQuery("this") .addParameter("that", null).build(); System.out.println(uri); What do you see as an expected result of this operation? '?this&that' or '?that'? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org