[
https://issues.apache.org/jira/browse/HTTPCLIENT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-750.
------------------------------------------
Fix Version/s: 5.4-alpha2
(was: Future)
Resolution: Fixed
Fixed by HTTPCLIENT-751
Oleg
> 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: HttpClient (classic)
> Reporter: Roland Weber
> Priority: Major
> Fix For: 5.4-alpha2
>
>
> 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 was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
