Hi, to explain the issues that I had with http client, consider the
following naive usage of http client:
URL url = new URL("http://jakarta.apache.org";);
HttpConnection connection = new HttpConnection(url.getHost(),
url.getPort());
HttpMethod method = new GetMethod(url.getPath());
method.setQueryString(url.getQuery());
connection.open();
connection.setSoTimeout(60000);
method.execute(new HttpState(), connection);
This wouldn't work because the following issues:
1)HttpConnection should handle default port number -1.
Currently, HttpConnection.open just takes whatever port number the user sets
and open the socket at the given port. While one can argue that it's the
user's responsibility to set the port correctly, it would be convinient if
the connection handles this common default case for the user just like JDK.
(JDK return -1 for url.getPort() in the above example)
2) HttpMethod should handle empty path.
ref to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6626
Currently, HttpMethod takes whatever path set by the user. In this case,
url.getPath() will return an empty string for "http://jakarta.apache.org";,
so HttpMethod will send something like:
GET HTTP/1.1
instead of
GET / HTTP/1.1
It would be nice to handle this common pitfall correctly as well.
3) HttpMethodBase shouldn't encode %.
ref to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6624
In HttpMethodBase.generateRequestLine
the path is always encoded using URIUtil.encode(reqPath,URIUtil.pathSafe()).
However, if the path already contains an encoding space, i.e. %20, the %
will
be encoded again, so we get %2520.
My argument is that when a URL has % in its path, it shouldn't be encoded
again. Otherwise, you would force user to use space in URL for httpclient.
e.g. instead of set path as
/bugzilla/some%20space%20bug
the use would need to set the path as
/bugzilla/some space bug
This is especially unacceptable if the user parsed this URL
(/bugzilla/some%20space%20bug) as a link from some webpage, then the user
will have to decode the path before set it in HttpMethod.
My suggestion is that we should never encode %, but other unsafe characters
in HttpMethodBase.generateRequestLine.
4) expose HttpConnection in class HttpClient
Currently, HttpClient doesn't expose the underlying HttpConnection. This
severly impacts the usage of this class, because some method like
setSoTimeout and set user agent need to access the underlying
HttpConnection.
5) redirect to a different host
It looks imcompatible to the design of http client. However it would be nice
if somebody can figure out a clean way to do it.
These are some simple issues, but they do affect the most common and simple
usage of http client. If you agree that these problems should be fixed, I
can fix them and post the patch here.
-Xiaowei
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
