On Fri, 2011-12-02 at 15:13 -0600, Stephen J. Butler wrote: > On Fri, Dec 2, 2011 at 2:04 PM, Oleg Kalnichevski <[email protected]> wrote: > > On Fri, 2011-12-02 at 13:13 -0600, Stephen J. Butler wrote: > >> For a project I'm working on I need to support RFC2817. Without going > >> too far into the details the process is: > >> > >> Client: send a request with a header telling the server we want to upgrade. > >> Server: send a response with the status code 101, telling the client to > >> continue > >> Client: start TLS handshake and switch the socket to an SSL one > >> Server: resends the original response, over TLS this time > >> > >> What I'm trying to figure out is the best way to hook into the latest > >> version of the HttpClient library. In v3 I hacked together something > >> in the socket factory. I could straight port this to v4+, but in v4+ > >> there's a lot more machinery available and I was wondering if there's > >> a better way to do things. > >> > >> My initial thought is to implement a HttpResponseInterceptor. It seems > >> like I can get the HttpConnection from the context through > >> ExecutionContext.HTTP_CONNECTION attribute. But can I call conn.bind() > >> with the new sslSocket? Will doing that sort of mid-request screw > >> things up? > >> > > > > Hi Stephen > > > > Protocol interceptors are for managing messages, not for managing > > connections. > > > > The proper place to implement RFC2817 would be in the > > HttpRequestExecutor which already handles the 'expect: continue' > > handshaking logic: > > > > http://hc.apache.org/httpcomponents-core-dev/httpcore/xref/org/apache/http/protocol/HttpRequestExecutor.html#221 > > > > Does this help? > > Thanks. That does help. > > I started looking into SocketHttpClientConnection and came to the > conclusion that in order to make it upgradable I will have to subclass > it. When you start TLS on an existing socket you get a new SSL socket > back and I don't see a way to tell SocketHttpClientConnection to use > the new SSL socket as a drop in. Among other things, it appears that > the Socket{Input,Output}Buffers store the socket input/output streams > and so would need some work. > > My plan right now is to subclass SocketInputBuffer, SocketOutputBuffer > (make them upgradable while maintaining the metrics), and > DefaultHttpClientConnection. > > It's good to know that HttpRequestExecutor.doReceiveResponse() will > loop for 1xx codes. Simplifies the logic in > UpgradeHttpClientConnection because I can just return the intermediate > response! >
Stephen 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. Oleg > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
