manage connections with upgradeable security
--------------------------------------------
Key: HTTPCLIENT-750
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-750
Project: HttpComponents HttpClient
Issue Type: New Feature
Components: HttpConn
Reporter: Roland Weber
Assignee: Roland Weber
Fix For: 4.0 Alpha 4
RFC 2817 (http://tools.ietf.org/html/rfc2817) specifies not only tunnelling of
TLS/SSL via proxies, but also upgrading an existing HTTP connection to TLS/SSL.
The latter is not commonly used for communication with traditional HTTP
servers, but part of other protocols like IPP that are based on HTTP.
The current connection management code assumes that a route planner can
determine in advance whether a connection will be secure or not. A connection
manager will not reuse an existing unsecure connection if a secure connection
is requested. It probably also doesn't consider a returned connection secure if
it wasn't requested for a secure route.
One way to improve the situation is to give HttpRoute a trinary security flag,
with values plain/secure for the current usage scenario and a new value
upgradeable for the new scenario. The two scenarios won't mix, but that is
probably not required.
We have to make sure that upgrade to security of an existing plain HTTP
connection is correctly tracked and either respected or suitably ignored by the
connection manager. If the security flag of the route is 'upgradeable', mixing
of scenarios is not required, and the actual security level can be obtained
from the connection itself, it is probably safe to let the connection manager
ignore it.
cheers,
Roland
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
