hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Tunneling non-HTTP through a web proxy with HttpClient
Date Fri, 26 Mar 2004 04:16:35 GMT
Hi Mike,

Given that HttpClient is in the business of communicating using HTTP, 
it is not terribly well suited for other purposes.  Having said that 
you should be able to hack something that works.  To get access to the 
secure tunneled socket I would recommend trying the following:

1) Create a NULL method as you describe.  It should do basically 
nothing except return a 200 status.
2) Change HttpConnection to add a method for getting the socket.
3) Create a custom http connection factory for managing the custom 
HttpConnections and their sockets.

With these three items you should be able to execute proxied methods as 
normal.  After executing a NULL method the connection manager would 
have access to the HttpConnection and socket to use as needed.

The only core HttpClient class you would need to change is 
HttpConnection I think.


On Mar 25, 2004, at 5:30 PM, m_sample@canada.com wrote:

> I have looked at HttpClient and it does not seem
> to offer a way to use it as simply a means of
> doing the CONNECT and proxy auth stuff and then
> returning the resulting Socket.  I would like to
> do this to tunnel a non-HTTP protocol,
> specifically the JXTA TCP-based protocol (not
> JXTA's HTTP stuff).
> Is there an way to do this with the existing
> HttpClient API?  The fact that HttpConnection
> holds the Socket as private instance variable
> and provides no get/setters suggests that there
> is not.
> If not, what do you think of the following
> suggestions to make HttpClient work for to this
> type of use. The design below is geared for the
> minimal distrubance of the existing HttpClient
> API and is not the cleanest way to do it.
> Changes to HttpClient:
> 1. augment the Protocol class to include a
>    "getProxySocketFactory()" method and make
>    HttpConnection class use this method instead
>    of creating DefaultProtocolSocketFactory for
>    secure and proxied connections. The Protocol
>    constructor that had the
>    SecureProtcolSocketFactory arg also needs an
>    additional arg to specifiy this new factory.
> 2. add public getSocket() and setSocket()
>    methods to the HttpConnection class.
> 3. Provide a NullMethod class whose execute()
>    method does nothing but keep the
>    HttpConnection parameter for later retrival
>    via getter on the NullMethod object.
> 4. Provide a NoOpSecureProtocolSocketFactory
>    whose create(socket,...)  method simply
>    returns back the socket argument.
> To use the above setup to tunnel through a web
> proxy you'd do the following
>     - create/register a Protocol object that
>       returns NoOpSecureProtocolSocketFactory
>       from its getSocketFactory and returns a
>       DefaultProtocolSocketFactory or other for
>       the new "getProxySocketFactory()" method
>       described above. In JXTA'S case the
>       proxySocketFactory would not be the
>       default one from HttpClient in order to
>       leverage Jxta's socket creation class for
>       the hop to the web proxy).
>     - create NullMethod object
>     - create HttpClient
>     - create HostConfiguration with appropriate
>       proxy info
>     - create HttpState and add appropriate
>       authentication credentials
>     - create SimpleHttpConnectionManager
>     - call httpClient.executeMethod(
>       hostConfiguration, nullMethod, httpState)
>     - get HttpConnection from NullMethod
>       (NullMethod captures httpConnection on its
>       execute() call)
>     - get Socket from HttpConnection and stash
>       it, then setSocket( null ) on
>       HttpConnection so releasing the connection
>       does not close it. This socket is the goal
>       of the whole exercise.
>     - httpState.getConnectinManger.releaseConnection();
> What do you think?
> Thanks in advance,
> /Mike Sample
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org

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

View raw message