On Sat, Dec 3, 2011 at 8:41 AM, Oleg Kalnichevski <[email protected]> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
