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