hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Httpcomponents Wiki] Update of "ClientConnectionManagementDesign" by RolandWeber
Date Sat, 23 Feb 2008 10:11:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpcomponents Wiki" for change notification.

The following page has been changed by RolandWeber:
http://wiki.apache.org/HttpComponents/ClientConnectionManagementDesign

The comment on the change is:
status in alpha3 and thoughts about HTTPCLIENT-652/-750

------------------------------------------------------------------------------
  See this [http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200701.mbox/%3c45B333F3.3010706@dubioso.net%3e
discussion] in the mail archive.
  
  
- == Implementation Review ==
+ == Implementation Review (HttpClient 3.1) ==
  
  The {{{SimpleHttpConnectionManager}}} in !HttpClient 3.x has exactly one connection. It
is re-used only for exactly the same route. No limits need to be enforced.
  
@@ -143, +143 @@

  [[BR]]
  See also this [http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200508.mbox/%3c304447CF-0A71-49C2-871D-5476E9F75226@symphonious.net%3e
discussion] in the mail archive.
  
+ 
+ = Status =
+ 
+ == HttpClient 4.0 alpha3 ==
+ 
+ Classes {{{HttpRoute}}} and {{{RouteTracker}}} are immutable and modifiable representations
of a route.
+ Route information includes flags whether the route is tunnelled, layered, or secure.
+ Route information excludes connection based authentication state.
+ The {{{ThreadSafeClientConnManager}}} (TSCCM) uses the same route-based management approach
as the
+ {{{MultiThreadedHttpConnectionManager}}} (MTHCM) in 3.x.
+ An {{{HttpRoutePlanner}}} is used to determine the route needed to execute a request in
advance.
+ That route is then requested from the TSCCM.
+ Connection release can be handled on the connection level, the entity level, and the stream
level.
+ There is a generic optional interface that is implemented on these levels.
+ An auto-close input stream similar to the one in 3.x takes care of the default release,
+ a managed entity can be used to close or abort the connection if the stream is not available.
+ 
+ This implementation seems to work well enough, with the same limitations as MTHCM in 3.x.
+ The first obvious problem is that it still ignores connection based authentication state
(CBAS).
+ The idea is to add CBAS as an additional information that the TSCCM has to consider when
+ selecting available connections from a pool. The impact of this change on the connection
management
+ code remains to be assessed.
+ ([http://issues.apache.org/jira/browse/HTTPCLIENT-652 HTTPCLIENT-652])
+ [[BR]]
+ A second problem is the missing support for upgrading security over an existing plain HTTP
connection,
+ as specified by [http://tools.ietf.org/html/rfc2817 RFC 2817].
+ Since the security flag is part of the route, the route of the connection after an upgrade
+ is different from the route before. TSCCM is not equipped to handle this distinction.
+ It cannot return an insecure route for upgrading when a secure route is requested.
+ Support for upgrading security might be squeezed in by always requesting an insecure connection,
+ and by managing the insecure and secure connections in the same pool of TSCCM.
+ This is very similar to the CBAS problem, as the (in)security of the connection should be
+ considered when selecting available connections from a pool.
+ ([http://issues.apache.org/jira/browse/HTTPCLIENT-750 HTTPCLIENT-750])
+ [[BR]]
+ Also, the {{{HttpRoutePlanner}}} is expected to determine the route, including security,
in advance.
+ This is incompatible with the notion that security of a connection is a runtime property,
which may
+ depend on the target host (intranet/internet) or the strength of a cypher suite chosen for
TLS/SSL.
+ 
+ In summary, the current implementation suffers from the same shortcomings as the 3.x one.
+ If support for CBAS is added, we should reconsider the approach for route representation
+ and maybe manage the flags (tunnelled, layered, secure) separately from the route and
+ together with the CBAS.
+ 

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


Mime
View raw message