Sung-Gu wrote:
Hi oglueck,
I'm not happy that you made the same methods with a diferrent-named method.
The encodeQuery and encodeInQuery are now same. :(
I have no idea who is gonna use encodeQuery anyway. In my opinion we can get rid of it.
http://host/path?query1=value1&query2=value2,This is completely clear to me. However, it is generally *not* possible to write a function f such that
if you encoded the whole query sequence like 'query1=value1',it shouldn't be encoded as 'query1%xxvalue1' but query1=value1.
f("http://host/path?query1=value1&query2=value2";) == "http://host/path?query1=value1&query2=value2";
where queryn and valuen may contain arbitrary characters (including =, &, ?). But this is exactly what you postulate should be encodeQuery. encodeQuery does not solve the encoding problem, it only tries to fix certain issues of it. It hides the real problem. This is dangerous for the user who might not have understood the whole depth of the problem. The unwary user might just use encodeQuery, think it's fine and will run into problems later.
So all implementations of encodeQuery (past and current) do not serve any reasonable purpose and thus have no right to exist.
The only safe way to encode a URL correctly is to treat query names and query values (not including the = sign) separated from the rest of the URL.
Odi
--
To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
