commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Dever <>
Subject Re: [httpclient] [proposal] Remove the "httpclient/methods/Url*Method" classes
Date Fri, 09 Aug 2002 02:29:36 GMT
Ok, back to basics here.

What are we trying to provide?  The sun HttpUrlConnection provides basic http
client side services.  We are trying to provide somthing more, a core library
for a http based client application.  We're doing redirects, forwards, proxies,
authentication, cookies and lots of other services that are desirable in a http
client application.

So what does a web client need to do then?  A web browser is the classic
example.  When a GET happens on a web page, a single URL is given and a single
connection is made to a particular webserver.  But in order to complete the
page load, the browser must parse the html and pull back all the embedded
images.  These might be on the same server with relative urls or they might be
on different servers with absolute urls.  Regardless of where the subsequent
GETs are made to, they are done in parallel for performance reasons.

So what does that mean for our HttpClient?  Initially it means that all the
information necessisary for performing a http request is in the URL.   We have
to manage multiple connections to different servers, which may or may not be
secure.  If we are handling the connections, then we will also be responseable
for parallelizing the requests.  There might be a proxy in the way as well, so
we have to handle that as well.

OK, so what does that mean for our HttpClient/MultiClient dilemma?  First of
all, the startSession methods in HttpClient stink.  It should just take a
method, execute it, and open a connection if required or reuse one if it is
already established.  Multiple concurrent calls to executeMethod should be

We should also not be too afraid of making changes to the public interface.
I started going through the classes to see what has been 1.0 and whats new in
2.0, and there is SO much new in the interface, and SO much removed (in the
case of the methods at least) that really we should take this as an opportunity
to provide a decent, clean, simple interface as the most important requirement
for 2.0.

Does that help? wrote:

> These methods were added to work with HttpMultiClient. HttpClient is a
> 'session' style object, you start a session with a host, execute URLs and
> end the 'session'.
> HttpMultiClient cares not what host URLs go to and is not a session style
> object, as the host is part of the URL.

I'm still in favour of removing the Url*Method classes, and doing the parsing
of the "path" as a full url and doing somthing useful with the scheme, host and
port, if they exist, and handling it as a path if its relative.

> This has been one of my main issues with the HttpClient/MultiClient
> classes - what sort of interface do we want to keep - the session style or
> non-session style? MultiClient can reasonably easily be retrofitted to
> handle a single 'default' session, but we need to make a decision on the
> API front.

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

View raw message