hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chang Sau Sheong" <csshe...@pacific.net.sg>
Subject Re: Let's face it: HttpClient API is more complex that it could have been
Date Thu, 12 Dec 2002 10:45:27 GMT
Totally agree.

But really the HttpClient code have improved quite a bit since the time I
used it when we had HttpMultiClient and HttpClient. Except for the
HostConfiguration thing, which had me scratching my head why the additional
layer of indirection (why not set the host and port directly?)

To add to this list -- what I think would be very useful is some way of
managing certs for SSL. I've actually done up something simple to do that,
wondering if the team wants to add this into the jar.

Also, the NTCredentials and UsernamePasswordCredentials classes -- seems
like they're not related at all except thru the 'shell' interface

What would be very useful is a way to determine the authentication method
i.e. if it is NTLM or Basic or Digest.

Just a suggestion.

elipva Ltd
----- Original Message -----
From: "Kalnichevski, Oleg" <oleg.kalnichevski@bearingpoint.com>
To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
Sent: Thursday, December 12, 2002 6:18 PM
Subject: Let's face it: HttpClient API is more complex that it could have

It's not the best time to discuss API changes at this point of time when the
focus should be put on polishing the existing code. However, I can't help
thinking that the HttpClient API could have been a bit more
straight-forward. Quite a few of the recent postings on this mailing list
were made by people having problems figuring out HttpClient's modus
operandi. Lack of documentation is partially to blame, but complex API does
not make things easier either. I was sort of thinking of an easy way to
explain how to get started with the HttpClient. Currently it almost takes a
PhD Stanford to get started with.

Ideally I would envisage the following pattern of use for the HttpClient

HttpClient client = new HttpClient();
HttpResponse response1 = client.execute(new
int result1 = response1.getStatusCode();
Header[] headers1 = response1.getHeaders();

HttpRequest get = new HttpGetRequest();
get.addQueryParam("param1", "stuff");
get.addQueryParam("param2", "stuff");

HttpResponse response2 = client.execute(get);
int result2 = response1.getStatusCode();
byte[] body2 = response1.getBody();

HttpRequest post = new HttpPostRequest();
post.addParam("param1", "stuff");
post.addParam("param2", "stuff");

HttpResponse response3 = client.execute(post);
int result3 = response3.getStatusCode();
String body3 = response3.getBodyAsString();

Bottom line:
- ideally HttpMethod interface should be split into HttpRequest/HttpResponse
- HttpClient.execute() should always work with full URLs. I feel that
client.getHostConfiguration().setHost(host, port); client.execute(path)
sequence is unnecessarily complex.
- The purpose of HttpMethod.recycle() may not be obvious to some
- We should think of a browser as a paradigm for HttpClient's "modus
operandi": start the damn thing, hit that url, get response, move to the
next one

Now everyone is welcome to start throwing bad tomatoes at me ;-)))


-----Original Message-----
From: Jeffrey Dever [mailto:jsdever@sympatico.ca]
Sent: Thursday, December 12, 2002 06:38
To: Commons HttpClient Project
Subject: [VOTE] 2.0 Alpha 2 release

I'm very happy to see HttpClient converging towards stability since the
recent set of major changes.  As far as I am concerned we have satisfied
all of our requirements to release a build at this time.

Originally this was supposed to be "Milestone 1".  This name was chosen
as it was perceived to be more standard in jakarta.  I beleive that this
was a bad choice for several reasons:
1) milestones, alpha, and beta are all used by various projects
2) the previous released build was alpha 1
3) it "feels" more like a late alpha than a milestone

** Therefore, I move that we release HttpClient 2.0 Alpha 2.  **

After this release, we will still be able to make significant changes,
but we should be converging towards stability as we approach Beta 1
where we will be focusing on bug fixes, documentation, stability and

Please, all contributors and committers vote, informally, yes or no, by
12:00 noon PST Thursday Dec 12th.

Release Prime,
Jeff Dever

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message