hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject [HttpConn][HttpClient] status update
Date Sat, 10 Feb 2007 13:20:30 GMT
Hi folks,

I've reached a milestone with ClientRequestDirector. The replacement
for HttpMethodDirector is now able to establish secure connections
through a proxy. Along with that goes a first draft of HttpClient
that uses the CRD. If you should look at the API at this stage, please
remember that I'm _really_ still working on HTTPCLIENT-627 [1] and
need the CRD as a sanity check of the connection management API.

The rest of this mail is implementation details and an outlook.

I did not "port" HttpMethodDirector to the new API, as I found the
approach much too difficult. HMD is based on the HttpMethod concept
and full of authentication related code, which is out of scope for
the current problem. Instead I had HMD open in one editor window
and implemented the CRD in another one, using a top-down approach
to provide similar functionality. Wherever I left out functionality
found in HMD, I put in a comment. Likewise when I felt there is
an open question. The CRD code now looks as if more questions
are posed than answered. It's a scrag, but I still feel that it
is on the right track and that the missing functionality can be
fitted nicely.
To implement the route-building logic, I have added new classes that
match my "HTTP route" idea. HttpRoute is meant as a replacement for
HostConfiguration, which I would like to keep in a different role
after HTTPCLIENT-618 [2]. ManagedClientConn and ClientConnManager
are updated to use HttpRoute rather than HostConfiguration. TSCCM
still uses HostConfig internally, as I don't want to start cleaning
it up until there are testcases to ease Oleg's mind.
There is one tiny little hole in the client API... connections can
not yet be released. The examples send an OPTIONS request, which
will generate a response without entity. In that case, the CRD
releases the connection immediately.
Connection release will be the next milestone. I'm thinking about
an approach that relies on closing the input stream or entity rather
than a releaseConnection method, as suggested in [4]. It will involve
AutoCloseInputStream and check for connection re-use and some kind
of extended interface (don't know which one yet) and I don't know
what else. If possible, I will address HTTPCLIENT-589 [3] along the
way, plus the questions I raised some weeks ago in [5]. After that,
it's time for testcases and review.


[1] https://issues.apache.org/jira/browse/HTTPCLIENT-627
[2] https://issues.apache.org/jira/browse/HTTPCLIENT-618
[3] https://issues.apache.org/jira/browse/HTTPCLIENT-589

To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

View raw message