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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
