Hi Oleg, all,
>> interface ClientConnection extends HttpClientConnection {
>> HttpHost getTargetHost(); // or simply getHost()
>> HttpHost getProxyHost();
>> Socket getSocket();
>> boolean isSecure();
>>
>> void open(Socket, boolean secure, HttpHost target, HttpHost proxy);
>> void reopen(Socket, boolean secure, HttpHost target, HttpHost proxy);
>>
>> // optional, for convenience if there is no proxy
>> void open(Socket, boolean secure, HttpHost target);
>> void reopen(Socket, boolean secure, HttpHost target);
>> }
>
> (1) This is actually not what I had in mind, but I think I am beginning
> to like it a lot. Really. Moreover, since this interface also allows us
> to keep tunneling stuff out of scope, we should actually consider
> putting it to HttpCore.
I'll start hacking it into HttpConn. Once we see how it's shaping up,
we can still move it to HttpCore.
> (2) No need to have #getSocket(). One can open a socket to the proxy and
> keep a reference to it, then bind the socket to an HttpConnection, send
> HTTP CONNECT request to the target host, and start using the socket to
> tunnel data via the proxy.
In the JavaDocs for reopen() {still looking for a better name...} will be
a note that the caller becomes responsible for closing the previoulsy
used socket if it is no longer needed. I don't expect that we will have
a use for this in the stock version, but I wouldn't like to put something
like that into an interface without providing access to the socket for
which the caller becomes responsible :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
