Mike, Laura, Adrian
In their pre-Java 1.4.1 form URLEncoder/URLDecoder classes are pretty
much unusable, as these classes always use default system charset, which
sometimes is not good enough. For instance, there's no way to properly
encode strings that simultaneously contain Cyrillic letters and
If not pre-encoded, the URI would look something like
http://host/path?param1=value1m2=value=2;.
Once joined together it is too late to encode. This is why the
HttpMethod(String) constructor assumes that all URIs are already
encoded, as it is not possible to correctly encoded them after the
Laura,
After looking into this some more I agree that query parameters should
be form urlencoded. The query param=value convention is an HTML
specification and has nothing to do with URIs. Fortunately it turns
out that form urlencoded values conform to the specification for URI
queries.
Michael Becke wrote:
I propose that we:
- form urlencode values passed to
HttpMethodBase.setQueryString(NameValuePair[])
- use java.net.URLEncoder for form urlencoding
I agree, as long as URLEncoder seems to work.
Do you think we need to modify URI so that it uses URLEncoder to encode
the
On Saturday, June 21, 2003, at 11:47 PM, Laura Werner wrote:
I agree, as long as URLEncoder seems to work.
Do you think we need to modify URI so that it uses URLEncoder to
encode the query part of URIs? In cases where a client has a URL
string that may or may not contain query parameters, it
I wish I'd done a bit more digging before my original post. It turns
out the problem is that parameters were being encoded *twice*. We were
encoding them once on our own, then the URI constructor was encoding
them again. My Mountain View example was being encoded as
Mountain%2520View. If
Michael Becke wrote:
Yes, but this is for application/x-www-form-urlencoded values.
Currently we only assume this content type for post params (this was
recently fixed).
I think we have to assume it for get params too. In the HTTP 4.01 spec,
17.13.3.4
