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? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
