hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Supporting RFC2817: Upgrading to TLS within HTTP/1.1
Date Mon, 05 Dec 2011 17:01:07 GMT
On Sun, 2011-12-04 at 17:30 -0600, Stephen J. Butler wrote:
> On Sat, Dec 3, 2011 at 8:41 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> > While this may be a viable strategy I actually think that a connection
> > class is the wrong place to implement this logic. The main
> > responsibility of HTTP connection classes is sending and receiving HTTP
> > messages. They are not supposed to contain HTTP protocol specific logic.
> > This is the responsibility of protocol handlers such as
> > HttpRequestExecutor.
> First off, thanks for letting me think out load about this!
> Hmmm... I've been thinking about this more, and reading more of the
> code. There's a lot of code to read and relationships to keep in mind!
> What I'm really doing is upgrading my IPP client code. FYI: IPP, both
> secured and unsecured, operates over port 631. RFC2817 is how you get
> a secured connection over port 631.
> Now that I'm more familiar with things, I'm thinking that what I need
> to do is register two schemes: ipp:// and ipps://. If the client gets
> back a 426 status code then rather than send upgrade headers itself it
> switches schemes to ipps:// and continues.
> What I'm doing is a lot like SSL through a proxy CONNECT. That means
> the proper place for this isn't HttpRequestExecutor but rather in a
> subclass of DefaultRequestDirectory and ilk. Hear me out:
> - ipps:// scheme returns that ipps is a layered protocol but not
> (necessarily) tunneled. This returns a route.
> - subclass of BasicRouteDirector in directStep() changes this logic:
>         if (plan.isSecure() != fact.isSecure())
>             return UNREACHABLE;
> to
>         if (plan.isSecure() && !fact.isSecure())
>             return UPGRADE_PROTOCOL;
> - subclass of DefaultRequestDirector overrides establishRoute() to
> handle the new step of UPGRADE_PROTOCOL. Modeled after
> createTunnelToTarget(), with the added step that it also incorporates
> managedConn.layerProtocol(). I'd like to do this as an extra step
> returned by the route director, but there's a response from the server
> to be consumed after the layering is done.
> - subclass DefaultHttpClient to get it to use my new request director.
> What I'm not sure about is how proxies will figure into this. If my
> route has a proxy and is also layered then I think the request
> director will attempt to CONNECT then layer, which isn't want I would
> want it to do. So maybe I need to also subclass HttpRoute to add a new
> method, isUgrade(), and not reuse this part of the layering code.
> Or I could just not support proxies in my code. Which right now is
> 100% acceptable. Because it looks like it would be a lot of work to
> subclass HttpRoute and actually use that.


I only took a cursory look at RFC2817, so I may well be wrong, but as
far as I understand connection upgrade is a hop by hop operation.
Basically the client always negotiates an upgrade to the next hop.
Therefore it really does not make a big difference whether the next hop
is the target server or an intermediate proxy. The protocol handling is
pretty much identical. 

The CONNECT method is a whole different story and unlike connection
upgrade may entail a rather complex client authentication process. This
is the primary reason why the CONNECT method needs to be handled by the
DefaultRequestDirector, which is the lowest protocol component capable
of HTTP authentication.  

The connection upgrade involves only a normal request / response
exchange, very much like the 'expect: continue' handshake and therefore
can be (and should be) handled by the HttpRequestExecutor in my opinion.
One would only need to abstract away the complexity of TLS machinery
behind an injectable strategy interface similar to SchemeSocketFactory.

Hope this helps


To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message