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? Then, assuming calling conn.bind() again works, from a HttpResponseInterceptor I don't see how I tell the library that it needs to re-read the response. At this point the response that it parsed is just the intermediary 101 response, and the real one is waiting on the wire. Or maybe the right approach is to subclass DefaultHttpClientConnection and make it safe to switch the socket mid request. In that case, I'm guessing I'd have to check the response returned from conn.receiveResponseHeader() for a 101 status code and perform my machinations at that point. Thoughts? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
