hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen J. Butler" <stephen.but...@gmail.com>
Subject Supporting RFC2817: Upgrading to TLS within HTTP/1.1
Date Fri, 02 Dec 2011 19:13:28 GMT
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.


To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message