commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ortwin Gl├╝ck <ortwin.glu...@nose.ch>
Subject Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestURIUtil2.java TestNoHost.java TestStreams.java
Date Mon, 28 Oct 2002 09:47:22 GMT
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,
> if you encoded the whole query sequence like 'query1=value1',it 
> shouldn't be encoded as 'query1%xxvalue1' but query1=value1.

This is completely clear to me. However, it is generally *not* possible 
to write a function f such that
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>


Mime
View raw message