hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HTTPCLIENT-750) manage connections with upgradeable security
Date Thu, 24 Apr 2008 18:17:22 GMT

     [ https://issues.apache.org/jira/browse/HTTPCLIENT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kalnichevski updated HTTPCLIENT-750:
-----------------------------------------

    Fix Version/s:     (was: 4.0 Alpha 4)
                   Future

I added support for managing stateful connections as per HTTPCLIENT-652. However, support
for connections with upgradeable security cannot be fully implemented until HTTPCORE-158 is
resolved.

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: HttpConn
>            Reporter: Roland Weber
>             Fix For: Future
>
>
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message