On Tue, 2017-05-09 at 00:21 -0700, Gary Gregory wrote: > Hi All, > > We have a nice example in HttpCore for an HTTP reverse proxy here: > > https://hc.apache.org/httpcomponents-core-4.4.x/httpcore-nio/examples > /org/apache/http/examples/nio/NHttpReverseProxy.java > > I've taken this example and morphed into a different beast. I am > wondering > how I can let each origin server client have its own SSLContext in > order > for me to given them different TrustStrategy implementations. > > In our example, we set things up like this: > > final IOEventDispatch *connectingEventDispatch *= new > DefaultHttpClientIODispatch( > clientHandler, ConnectionConfig.DEFAULT); > > final IOEventDispatch listeningEventDispatch = new > DefaultHttpServerIODispatch( > serviceHandler, ConnectionConfig.DEFAULT); > > Thread t = new Thread(new Runnable() { > > public void run() { > try { > connectingIOReactor.execute(*connectingEventDispa > tch*); > } catch (InterruptedIOException ex) { > System.err.println("Interrupted"); > } catch (IOException ex) { > ex.printStackTrace(); > } finally { > try { > listeningIOReactor.shutdown(); > } catch (IOException ex2) { > ex2.printStackTrace(); > } > } > } > > }); > t.start(); > > > In my case I build the connectingEventDispatch with our lower-level > APIs in > order to pass in the SSLContext like this: > > ConnectionConfig clientConnectionConfig = ConnectionConfig.DEFAULT; > IOEventDispatch *connectingEventDispatch *= > clientSslContext == null ? > new DefaultHttpClientIODispatch(clientHandler, > clientConnectionConfig) > : > new DefaultHttpClientIODispatch(clientHandler, > *clientSslContext*, > clientConnectionConfig); > > But this SSLContext is used for ALL origin servers (a.k.a. target > hosts) > > Do I need to build a connectingEventDispatch for each SSLContext I > need and > then execute each like the above: > > connectingIOReactor.execute(connectingEventDispatch); > > Each execute in its own thread? > > Or is there a cleaner, more HttpCore way to do this? >
I suppose the IOEventDispatch#onConnect would be the right place to implement TLS upgrade. One can employ various strategies here, for instance, passing some sort of config object as an attachment to the session request and building SSL context for the session based on that config. Oleg PS: I hope that TLS upgrade APIs in 5.0 are much nicer. > Thank you! > Gary > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
