commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sung-Gu" <jeri...@apache.org>
Subject Re: cvs commit: jakarta-commons/httpclient/src/test/org/apache/commons/httpclient TestURIUtil2.java TestNoHost.java TestStreams.java
Date Fri, 25 Oct 2002 16:53:16 GMT
Hi oglueck,

I'm not happy that you made the same methods with a diferrent-named method.
The encodeQuery and encodeInQuery are now same.  :(

Please refer to the below, why they're required.

Sung-Gu

----- Original Message -----
From: <oglueck@apache.org>

>   1.7       +6 -5
jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/util/URIUt
il.java
>        // ---------------------------------------------------------- URI
utilities
>   @@ -371,7 +372,7 @@
>        public static String encodeQuery(String unescaped, String charset)
>            throws URIException {
>
>   -        return encode(unescaped, URI.allowed_query, charset);
>   +        return encode(unescaped, allowed_in_query, charset);
>        }

I think we haven't understood each other enough yet...
Actually,  as an default example,
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.

EAXMPLES:

encodeQuery(assertTrue case):
    query1=value1 -> query1=value1
encodeQuery(assertTrue case):
    query1=value1&query2=value2 -> query1=value1&query2=value2
encodeQuery(assertFalse case): http://host/path?query=1=value=1
    <Reference #1>
    query=1 -> query=1
    value=1 -> value=1
    query=1=value=1 -> query=1=value=1

encodeInQuery(assertFalse case):
    query1=value1 -> query1%xxvalue1
encodeInQuery(assertFalse case):
    query1=value1&query2=value2 -> query1%xxvalue1%xxquery2%xxvalue2

encodeInQuery(assertTrue case):
    query1 -> query1
    value1 -> value1
encodeInQuery(assertTrue case):
    query2 -> query2
    value2 -> value2
encodeInQuery(assertTrue case): http://host/path?query=1=value=1
    <Reference #1>
    query=1 -> query%xx1
    value=1 -> value%xx1
encodeInQuery(assertFalse case): http://host/path?query=1=value=1
    query=1=value=1 -> query%xx1%xxvalue%xx1
encodeInQuery and encodeQuery(assertTrue case):
http://host/path?query=1=value=1
    <Reference #2>
    query=1=value=1 -> query%xx1=value%xx1
encodeAll and encodeQuery and (assertTrue case):
http://host/path?query=1=value=1
    <Reference #2>
    query=1=value=1 -> %xx%xx%xx%xx%xx%xx%xx=%xx%xx%xx%xx%xx%xx%xx

Reference #1: cases a user want the name as 'query=1' and the value as
'value=1'
Reference #2: encodeQuery might mean the real 'encodeQuery' or string
literals for
allowed_query bitset.

[ in details ] -------------------------------------------------------------

So the encodeInQuery method is recommended  within a query.
And the encodeQuery method is recommned for the whole query string by
treating an octet sequence.
Actually both aren't incorrect.

URI does not force not to have =, &, ?, #
But in case of having ? or #, that means the special purpose.
So those characters shounld't be used in the URI sequence.
But it's not restricted not to use ? and # signs again on the whole URI
escaped sequence.
That's another reason why the encodeQuery method is still required.
(Or it will be used by a string literal in HttpClient, mostly now with
encodeInQuery.)
The encodeInQuery method is required to have some special characters like ?.

So the API programmer is noticed not to use some special characters,
the encodeQuery method for using allowed_query bitset is a best-use case.
Otherwise, the encodeAll or encodeInQuery methods might be better.
For this reason, I write down the javadoc message to use one or combination
of
encodeAll, encodeInQuery or encodeQuery.


--
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