Contributed Code: Proxy Tunnels for binary protocols
[ Sorry I had to remove the zip because it was bounced by the list - pls let me know where or to whom it should be sent - MS ] Greetings, A while back we discussed some changes I proposed to allow one to use HttpClient to negotiate with a web proxy (authentication and tunnel via CONNECT) in order to create a TCP connection for use by arbitrary (even binary), non-HTTP protocols, in my case JXTA over TCP. This was basically all about providing direct access to the Socket underylying a HttpConnection. Anyhow, I have done those modifications and introduced the 'NullMethod' class. These changes are in the attached zip. Also included in the zip are changes to make Jxta-TCP use this web proxy tunneling ability. These modifications were written by me and are courtesy of my employer, Ecmarket. They are released to the public domain. Please see the LICENCE.txt file in the attached zip. I hope these changes or changes of a similar nature will be included in future versions of HttpClient. I believe providing access to the Socket will be very useful (for example I wrote a program to tunnel SSH through a web proxy using these mods). Cheers, /Mike Sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contributed Code: Proxy Tunnels for binary protocols
Hi Mike B. I have created bug# 28151 and attached the source. I believe my employer would be ok with the Contributor Agreement if that is what your are referring to, and I to the individual contributor agreement. If that is what you need, let me know and I'll talk to them and get faxing. /Mike Sample Hi Mike, It sounds like you made some interesting and useful additions. Please attach the code to a new bug in Bugzilla to share with everyone else. Some of your changes might prove to be good additions to the HttpClient code base. In order for them to be included though they would need to be licensed with the Apache 2.0 license. I don't know if this is an option for you, but please let us know. Thanks, Mike On Apr 1, 2004, at 9:59 PM, [EMAIL PROTECTED] wrote: [ Sorry I had to remove the zip because it was bounced by the list - pls let me know where or to whom it should be sent - MS ] Greetings, A while back we discussed some changes I proposed to allow one to use HttpClient to negotiate with a web proxy (authentication and tunnel via CONNECT) in order to create a TCP connection for use by arbitrary (even binary), non-HTTP protocols, in my case JXTA over TCP. This was basically all about providing direct access to the Socket underylying a HttpConnection. Anyhow, I have done those modifications and introduced the 'NullMethod' class. These changes are in the attached zip. Also included in the zip are changes to make Jxta-TCP use this web proxy tunneling ability. These modifications were written by me and are courtesy of my employer, Ecmarket. They are released to the public domain. Please see the LICENCE.txt file in the attached zip. I hope these changes or changes of a similar nature will be included in future versions of HttpClient. I believe providing access to the Socket will be very useful (for example I wrote a program to tunnel SSH through a web proxy using these mods). Cheers, /Mike Sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tunneling non-HTTP through a web proxy with HttpClient
Here's a thought - provide get/setSocket in HttpConnection but make them protected. Then those who want to use them have to work harder (ie make a subclass) and will probably be less likely to use them incorrectly. Joe average user is unlikely to confused by them or use them this way. /Mike Sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tunneling non-HTTP through a web proxy with HttpClient
On Fri, 26 Mar 2004 13:18:02 -0500, Michael Becke wrote: 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. Hi Guys, My 2 cents on this is that it should be the Socket, not i/o streams, although more work is involved and there is a control issue at stake (who owns the Socket, making it null in the HttpConnection to detach it etc. etc). By making the Socket available, you can almost guarantee easy intergration with any Java app that uses Sockets for some protocol, but needs to be augmented to get through a web proxy. How about this approach: for the existing version, a quick get/setSocket on HttpConnection with the advisory to be careful and that things may change for 4.0. In 4.0 more care can go into the design wrt control issues etc. but I would still recommend some way to get at the Socket in 4.0. Augmenting the Protocol class for those where isSecure() returns true to have a SocketFactory for the first hop would be great too. This could be added via a new Protocol constructor (so existing stuff doesn't break) and by making the existing Protocol ctor use the DefaultProtocolSocketFactory for the first hop by default (as is currently embedded in the HttpConnection code, I believe). Add this to the method to get this socket factory I mentioned before. I'd be happy to add these changes and send them to someone to check in (2 files for the Protocol stuff). Of course, I have an ulterior motive - I would like to contribute my changes to JXTA for enabling their TCP protocol to tunnel through web proxies using HttpClient. Without access to a Socket from HttpClient, I would have to offer the JXTA changes as well as a hacked version of HttpClient - not likely to help too many people that way. Sorry for a delayed reply - I just got back from a short ski trip on the Wapta Icefield (Banff National Park, Rockies). Fun! Regards, /Mike Sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tunneling non-HTTP through a web proxy with HttpClient
Thanks for the confirming my plans. I appreciate the feedback. Would the HttpClient project consider including the get/setSocket changes? The Protocol changes would be nice to avoid the hardwiring of the connection to the web proxy but I can live with out that. The Jxta code does some clever use of reflection so they can get the best of JDK 1.4 without needing to be compiled with 1.4. Thanks /Mike Sample - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
