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: another idea about authentication states, introduced subsections ------------------------------------------------------------------------------ = Design Ideas = + == Connection Management == + Connections should be requested from a connection manager with a specification of the intended route. The connection manager returns a connection which is either closed, matches the route exactly, or is a prefix of the route. We need representations for the intended route and for the actual route of the returned connection. Connection managers can compute internal keys for connection lookup based on the routes. Routes are established outside of the connection manager. When the connection is released, the connection manager needs to know which route has actually been established. The connection may be closed, the full route may have been established, or a prefix thereof. Of course there might also be misbehaving applications that establish a route different from the one for which the connection was allocated. @@ -80, +82 @@ * authenticate against target/proxy (connection based authentication only) Optionally, establishing of a route different from the intended one could be prevented by the connection or connection manager. + == Routes == + Route representation does not need to cover routes of arbitrary length. For practical purposes, there will be at most two hops: target and proxy. A modifiable route representation is useful for tracking. A non-modifiable route representation could be useful for lookup keys and return values. A sophisticated connection manager will probably need different lookup keys though. Options: * route interface plus both a modifiable and non-modifiable implementation, similar to {{{StringBuilder}}} and {{{String}}} * 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) and tunnelling state 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. + 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. [[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. * {{{SSLSocketFactory}}} for TLS/SSL with client authentication. The socket factory uses a unique key store, so the same credentials would be available and the authentication state can be re-used. * A key store for TLS/SSL with client authentication. This is a variation of the {{{SSLSocketFactory}}} option. * application specific user object for applications dealing with more complex multi-user scenarios - Modifiable objects for representation of authentication state have implications if used in a non-modifiable route representation. This would need to be documented carefully, but the problem is not different from using modifiable objects as lookup keys. + The drawback of using {{{Object}}} to represent authentication state is that only a single level of authentication can be used. Multiple connection based authentication levels, for example adding NTLM authentication on top of TLS/SSL with client authentication, would not be covered. (No, that example doesn't make sense.) + [[BR]] + Alternatively, an interface for the authentication state could be defined with two comparison methods for checking whether a state is reachable by means of ''upgrading'' from another one. Ease of use in the most common situations can be achieved by a default implementation that wraps an {{{Object}}} and maps both methods to {{{equals}}} on that object. Two methods are needed so that both authentication states, the current one and the intended one, can decide that the upgrade is not permissible. + Modifiable objects for authentication states have implications if used in a non-modifiable route representation. This would need to be documented carefully, but the problem is not different from using modifiable objects as lookup keys. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
