You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by m_...@canada.com on 2004/03/25 23:30:42 UTC
Tunneling non-HTTP through a web proxy with HttpClient
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
RE: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Sam Berlin <sb...@limepeer.com>.
Access to the socket (plugging in the initial socket, or some other means) would be very useful. For example, in the Gnutella world there is what's known as a 'push' -- when client B is firewalled and client A (not firewalled) wants to connect to B. To accomplish this, A sends a message through the network telling B to connect to him and then (after B connects) A proceeds as normal (as if A had made the outgoing connection in the first place). It is currently impossible to use HttpClient's functionality in these situations.
Thanks,
Sam
-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu]
Sent: Friday, March 26, 2004 1:18 PM
To: Commons HttpClient Project
Subject: Re: Tunneling non-HTTP through a web proxy with HttpClient
Hi Roland,
> Of course, that is only required if the socket doesn't create
> new input and output streams for each connection anyway.
> As you have guessed by now, I agree that not the socket itself
> but only the streams should be made available.
Yes, I think this is the big question. Is having access to the I/O
streams enough or would someone need access to the actual Socket? If
it's just the streams then I think we can probably do this now. If we
need access to the socket then we need to rethink things a little.
Mike
---------------------------------------------------------------------
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
Re: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Michael Becke <be...@u.washington.edu>.
Hi Roland,
> Of course, that is only required if the socket doesn't create
> new input and output streams for each connection anyway.
> As you have guessed by now, I agree that not the socket itself
> but only the streams should be made available.
Yes, I think this is the big question. Is having access to the I/O
streams enough or would someone need access to the actual Socket? If
it's just the streams then I think we can probably do this now. If we
need access to the socket then we need to rethink things a little.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Mike,
(for 4.0) we can wrap input and output streams around those
of the underlying socket. Connection reuse is not an option for
that method anyway, and by help of the wrapper we can cut
any references to the underlying socket's input and output
streams as soon as the connection manager gets back the
connection.
Of course, that is only required if the socket doesn't create
new input and output streams for each connection anyway.
As you have guessed by now, I agree that not the socket itself
but only the streams should be made available.
cheers,
Roland
Michael Becke <be...@u.washington.edu>
26.03.2004 14:44
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<co...@jakarta.apache.org>
cc:
Subject: Re: Tunneling non-HTTP through a web proxy with
HttpClient
> Hi Mike & Mike
:)
> Since CONNECT is also an HTTP method, it is not totally
> out of scope for the HttpClient. From RFC 2616, section 9.9:
Agreed. CONNECT is definitely an HTTP method. The only question is if
we should support it's use in non-HTTP contexts.
> Maybe we can consider official support for CONNECT
> as a feature for the big 4.0 API overhaul.
It seems like it could be a good addition. My only hesitation is in
giving direct access to the Socket. This seems like a pretty major
departure from our current system.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org
Re: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Michael Becke <be...@u.washington.edu>.
> Hi Mike & Mike
:)
> Since CONNECT is also an HTTP method, it is not totally
> out of scope for the HttpClient. From RFC 2616, section 9.9:
Agreed. CONNECT is definitely an HTTP method. The only question is if
we should support it's use in non-HTTP contexts.
> Maybe we can consider official support for CONNECT
> as a feature for the big 4.0 API overhaul.
It seems like it could be a good addition. My only hesitation is in
giving direct access to the Socket. This seems like a pretty major
departure from our current system.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Mike & Mike
Michael Becke wrote:
> Given that HttpClient is in the business of communicating using HTTP,
> it is not terribly well suited for other purposes.
Since CONNECT is also an HTTP method, it is not totally
out of scope for the HttpClient. From RFC 2616, section 9.9:
> This specification reserves the method name CONNECT
> for use with a proxy that can dynamically switch to being
> a tunnel (e.g. SSL tunneling [44]).
Maybe we can consider official support for CONNECT
as a feature for the big 4.0 API overhaul.
cheers,
Roland
Re: Tunneling non-HTTP through a web proxy with HttpClient
Posted by Michael Becke <be...@u.washington.edu>.
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.
Mike
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