Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.160.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1340714618.5475.24.camel@ubuntu>
References: 
 <CAOGo0VZC=3FnQaS-ipBbhQYCi7ZZLLJ771qKQBeOT0y=jrOwqg@mail.gmail.com>
	<1340714618.5475.24.camel@ubuntu>
Date: Tue, 26 Jun 2012 14:33:41 +0100
Message-ID: 
 <CAOGo0VbXdT6L-MsqcN60i1sE2BsWYHt02qqNkHtUcBEcke_b_A@mail.gmail.com>
Subject: Re: URIBuilder setQuery() method inconsistent with other set methods
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 26 June 2012 13:43, Oleg Kalnichevski <olegk@apache.org> 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.

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.

> 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