Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-httpclient Wiki" for change notification.
The following page has been changed by RolandWeber: http://wiki.apache.org/jakarta-httpclient/ConnectionManagementDesign The comment on the change is: yet more details making things tricky ------------------------------------------------------------------------------ tunnelled via proxy:: The connection is tunnelled via a proxy to a target, typically for communication with TLS/SSL. It can be re-used for exactly this route. - Reusability can also be affected by the authentication state of a connection. + Reusability can be affected by the authentication state of a connection. If TLS/SSL with client authentication is used, a connection identifies the user to the target. With NTLM authentication, the connection identifies the user to the proxy or target. Re-use of an authenticated connection for requests from a different user is a security breach. While TLS/SSL client authentication is out of scope for !HttpComponents, NTLM authentication is not and needs to be considered. + [[BR]] + Reusability can also be affected by the local host address being used. On machines with more than one network interface, applications might have specific requirements as to which of the interfaces is used for communication. == Implementation Review == @@ -63, +65 @@ 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. The {{{MultiThreadedHttpConnectionManager}}} in !HttpClient 3.x keeps a pool of connections. Re-use depends on exact matches of the route. Limits are enforced per route. In other words, the maximum connections per host are interpreted as maximum connections per route. If multiple proxy servers are available, the maximum per host can be exceeded by using different routes to the target host. This has not been a problem in the past. + [[BR]] + The {{{HttpMethodDirector}}} in !HttpClient 3.x will use an allocated connection for different targets when following redirects, thereby evading the limit per host (or route) enforced by the connection manager. A more sophisticated connection manager could provide performance benefits for !HttpClient 4.x. In particular, re-use of plain connections to a proxy for all routes via that proxy has potential. Even more so if the proxy requires NTLM authentication and the previous authentication state can be re-used. + [[BR]] + Correct enforcement of connections per host limits on a per-host basis in the presence of redirects requires changes to both the connection management and the redirect handling logic. = Design Ideas = @@ -92, +98 @@ * modifiable route representation only, similar to {{{HostConfiguration}}} in !HttpClient 3.x The target and proxy can be represented by {{{HttpHost}}} objects. This identifies schemes (HTTP, HTTPS) by their name. It does not cover cases where applications use different socket factories for the same scheme. That's not likely to be a problem. [[BR]] - Route length (direct/proxied), tunnelling state, and security can be represented by {{{boolean}}} values. Using {{{int}}} for the route length would allow for custom implementations of more complex routes (with the interface option), but the restriction to two hops will probably show up elsewhere too. Multiple levels of security are not considered in the HTTP area. + Route length (direct/proxied), tunnelling state and layered/plain can be represented by {{{boolean}}} values. Using {{{int}}} for the route length would allow for custom implementations of more complex routes (with the interface option), but the restriction to two hops will probably show up elsewhere too. + Multiple levels of layering are hypothetical and therefore not considered. [[BR]] Generic {{{Object}}} instances can be used to represent connection based authentication state. Two objects are required for proxy and target authentication. Comparison relies on the generic {{{equals}}} method. Applications can use whatever is considered appropriate to represent the authentication, for example: * {{{CredentialsProvider}}} for NTLM authentication. If a route is requested with the same {{{CredentialsProvider}}}, the same credentials would be available and so the authentication state can be re-used. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
