Re: [HttpConn] connection interface and implementation

[Roland Weber <ht...@dubioso.net>]

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: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org

Re: [HttpConn] connection interface and implementation

[Roland Weber <ht...@dubioso.net>]

Hi all,

just to give you an idea of what I'm doing...

I had an eye opener while pondering Oleg's last remark about
tunnelling. In fact, the connection manager does not only need
to know which target host and which proxy is used, it also has
to know whether the connection is _tunnelled_ through that host
or not. While typically SSL connections will be tunnelled and
plain connections will not, we shouldn't rely on this.

In consequence, I have come to the conclusion that it would be
too complex and cumbersome to put all the data which a connection
manager might require into a single open(...) call. I am going
to define two interfaces:

interface UnmanagedClientConnection { // name temporary
   HttpHost getTargetHost();
   boolean  isSecure();
   Socket   getSocket();
   void open(...);
   void update(...); // used to be reopen(...)
}

interface ClientConnection {
   // all the stuff a connection manager might require
}

An inital version of the first interface is already checked in.
The methods defined there are candidates for moving to HttpCore,
that's why I chose the longer name for this interface: it might
go away.
In the first interface, there is no notion of proxy vs. target
host anymore. The target host is simply the host to which
requests will be sent. That might be a proxy, or the final server.
If a tunnel is created, the target switches from the proxy host
to the tunnel target host.

The second interface requires some more thinking on my part.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org