Hi all, I've spent some time on reworking interfaces for HttpConn. While the work is far from completed, some of the interfaces are ready for review. As usual, I've spent more time than I had planned, so I need to declare a break here in order to take care of some other stuff for a while. I'll just give you a summary of the changes and an outlook.
=== Changes === I didn't touch the old code moved over from HttpClient 3.x. We have two new interfaces, with default implementations: - org.apache.http.conn.UnmanagedClientConnection A connection with the methods needed to open and tunnel. It does not provide the data needed by a connection manager, so it can not replace the old HttpHostConnection. - org.apache.http.conn.SocketConnectionOperator Encapsulates the knowledge about using SocketFactory and SecureSocketFactory in order to open or update an UnmanagedClientConnection. It does not know about tunnelling. This interface is meant to be thread safe. We could also change the name to include a "Client" somewhere. Since HttpConn is currently part of HttpClient, I forgot that when I chose the name. - Two examples show how to use the SocketConnectionOperator. I learned quite a bit about tunnelling TLS/SSL connections through proxies when coding the second example :-) === Outlook === a) Extended connection interface. We do need another connection interface that provides additional methods for connection management. The name I have in mind is "ClientConnection", that's why the default implementation of UnmanagedClientConnection is already called DefaultClientConnection. I have had some ideas, and some more ideas, and yet other ideas about this interface. In the end, they are pointless. I can't develop the interface without rewriting the connection manager to see what is actually needed. That's a major effort, and I can't tell yet when I will have the time. b) Encapsulate tunnelling logic. The SocketConnectionOperator does only half of the job when opening a secure connection through a proxy. It is missing the tunnelling logic. Since tunnelling requires generating HTTP requests, it is something that can not simply be hidden in a socket factory or connection manager. In HttpClient 3.x, the method director knows about tunnelling. That class is rather inflexible and designed exclusively for a blocking scenario. Reworking it is another major effort. I'd like to have an interface where you feed in a few parameters and which then tells what to do next: create a tunnel, retry with authentication, follow a redirect, and so on. This might be an occasion to revisit HTTPCLIENT-63. https://issues.apache.org/jira/browse/HTTPCLIENT-63 c) Determine socket security dynamically. This point is somehow separate from connection interfaces, but I stumbled across it again when implementing the default socket connection operator. I'd like to have a method SocketFactory.isSecure(Socket) to query dynamically whether a socket should be considered secure or not. I dislike instanceof checks to determine object behavior. They tie runtime properties to a static class hierarchy. This change should not take more than a few hours to implement. I'd like to get some feedback on the idea, then I would tackle it on the next free weekend. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
