hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen J. Butler" <stephen.but...@gmail.com>
Subject Re: Supporting RFC2817: Upgrading to TLS within HTTP/1.1
Date Thu, 08 Dec 2011 00:04:01 GMT
On Mon, Dec 5, 2011 at 11:01 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> 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.

Okay, let's say I modify HttpRequestExecutor.

- In HttpRequestExecutor#doReceiveResponse I'd need to look for
HttpStatus.SC_SWITCHING_PROTOCOLS and handle that specially.

- Check to see if the conn implements ManagedClientConnection so that
I can call layerProtocol(). Call layerProtocol().

- Except now in AbstractPoolEntry#layerProtocol() I violate this check
on line #259:

         if (!this.tracker.isTunnelled()) {
            //@@@ allow this?
            throw new IllegalStateException
                ("Protocol layering without a tunnel not supported.");

Yes, we should allow this :) But for me to get around it, now I'm
subclassing something in the AbstractPoolEntry hierarchy and that
means I'm subclassing the connection managers. Ugg.

But let's assume I get around the code in
AbstractPoolEntry#layerProtocol. Then I start to think about how do I
even trip the new code path in HttpRequestExecutor? Suppose I let the
user of the code determine when to upgrade a connection. They either
issue a normal request with a "Connection: upgrade" header or a
mandatory upgrade (OPTIONS * blah blah blah). But then I have the
problem that if the user is using the ThreadSafeClientConnManager that
some of the connections in the pool are upgraded and some aren't. That
sounds like a nightmare.

So suppose I create a new scheme, 'ipps', and ensure that all
connections in the pool for this scheme are upgraded before being
returned for use. Now I'm back in DefaultRequestDirector and
BasicRouteDirector doing the upgrade as part of establishing the route
(because the upgrade is mandatory for this route) whether or not the
actual SC_SWITCHING_PROTOCOLS is handled inside HttpRequestExecutor.

Now I'm at subclassing these to implement new logic:

HttpRequestExecutor (handle SC_SWITCHING_PROTOCOLS)
DefaultRequestDirector (force upgrade for new scheme)
BasicRouteDirector (return the mandatory upgrade step)
BasicPoolEntry (override the isTunneled() check)
PoolEntry in SingleClientConnManager (ibid)

And then I'm subclassing these to use my new classes:


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

View raw message