hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpConn][HttpClient] status update
Date Sat, 10 Feb 2007 16:59:56 GMT
On Sat, 2007-02-10 at 14:20 +0100, Roland Weber wrote:
> 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.

Hi Roland,

Just got the first cut at NIO SSL working on both the client and the
server side. With the b**ch of NIO SSL almost off my back I would like
to spend a few more days working on the outstanding HttpCore issues and
then turn my attention to HttpConn and HttpAuth. I'll do my best to
review the recent changes in HttpClient and give you some feedback by
the next week.

Feel free to go ahead and remove all deprecated classes if they are no
longer of any use. The fewer classes to review the better.



> cheers,
>   Roland
> [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
> [4]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
> [5]
> http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

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

View raw message