[HTTPCLIENT-750] manage connections with upgradeable security

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 5.4-alpha2
• Component/s: HttpClient (classic)
• Assignee: Unassigned
• Reporter: Roland Weber
• Created: 17/Feb/08 17:10
• Updated: 31/Jan/24 10:44
• Resolved: 31/Jan/24 10:44

Description

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

Issue Links

• depends upon: HTTPCLIENT-652 Add optional state attribute to managed client connections
• is blocked by: HTTPCORE-158 Support for 'Upgrade' request header / 101 (Switching Protocols) response (as defined per RFC 2817)