Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <1340696770.5475.6.camel@ubuntu>
Subject: Re: URLEncodeUtils - change in format behaviour since 4.2
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Tue, 26 Jun 2012 09:46:10 +0200
In-Reply-To: 
 <CAOGo0VaWzE7FQGt3oJaMdC0GUXhgp5k-Wk1mKd97-PhjQnnKpA@mail.gmail.com>
References: 
	<CAOGo0VaWzE7FQGt3oJaMdC0GUXhgp5k-Wk1mKd97-PhjQnnKpA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0

On Tue, 2012-06-26 at 02:00 +0100, sebb wrote:
> The escaping of non-alphabetic characters by the format methods is no
> longer quite the same as that done by java.net.URLEncoder.encode.
> 
> The former allows the chars in ".-*_!'()" to pass through without
> conversion, whereas the latter only allows ".-*_" unchanged.
> The latter is also how browsers behave when escaping form fields.
> 
> I think the behaviour should be consistent with URLEncoder and browsers.
> That was in fact the behaviour with 4.2, which delegated the escaping
> to URLEncoder.
> I think the code should revert to using URLEncoder/URLDecoder.
> 
> There is still a need for the extended path, query and fragment
> escape/unescape methods, but perhaps these belong in URIBuilder?
> If not, maybe they should be in a separate class anyway?
> 

Would not that lead to inconsistent behavior when the same query form
gets encoded differently depending on whether it is enclosed in the
request URI or in the request body?

Browsers do a lot of silly stuff to maximize compatibility with all
sorts of broken software out there. I am not sure we need to do
likewise.

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