Re: Tunneling non-HTTP through a web proxy with HttpClient

[m_sample]

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]

Re: Tunneling non-HTTP through a web proxy with HttpClient

[Michael Becke]

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, [EMAIL PROTECTED] 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: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tunneling non-HTTP through a web proxy with HttpClient

[m_sample]

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]

DO NOT REPLY [Bug 20089] - Authentication fails with proxied SSL Connections

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=20089

Authentication fails with proxied SSL Connections

This bug depends on bug 25529, which changed state:

   What|Old Value   |New Value

 Status|REOPENED|RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 10794] - User interaction for authentication

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=10794

User interaction for authentication

This bug depends on bug 25529, which changed state:

   What|Old Value   |New Value

 Status|REOPENED|RESOLVED
 Resolution||FIXED

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25529] - Redesign of HTTP authentication framework

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=25529

Redesign of HTTP authentication framework

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-03-25 20:38 ---
Patch committed.

Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: EasySSLProtocolSocketFactory for Secure and Proxied.

[Eric Johnson]

The initial "connection" to the proxy server is actually done over an 
unencrypted channel.

Subsequent communications are encrypted only after the connection to the 
proxy has been established.

This isn't a "restriction", rather I believe it follows the proxy 
specification.

-Eric.

John Melody wrote:

Hi, 

I have just been trying to get my httpclient to accept a 
self signed certificate on a secure, proxied connection. I 
followed the SSL guide directions but it did not seem to be 
picking up my new factory. 

When I checked in the source code I noticed the following code. 

HttpConnection.java 

  // use the protocol's socket factory unless this is a secure
   // proxied connection
   final ProtocolSocketFactory socketFactory =
   (isSecure() && isProxied()
   ? new DefaultProtocolSocketFactory()
   : protocolInUse.getSocketFactory());

 

Why is this restiction in place? 

regards, 
John.  

John Melody 
SyberNet Ltd. 
Galway Business Park, 
Dangan, 
Galway. 
Tel. No. +353 91 514400 
Fax. NO. +353 91 514409 
Mobile - 087-2345847 

-
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]

EasySSLProtocolSocketFactory for Secure and Proxied.

[John Melody]

Hi, 

I have just been trying to get my httpclient to accept a 
self signed certificate on a secure, proxied connection. I 
followed the SSL guide directions but it did not seem to be 
picking up my new factory. 

When I checked in the source code I noticed the following code. 

HttpConnection.java 

   // use the protocol's socket factory unless this is a secure
// proxied connection
final ProtocolSocketFactory socketFactory =
(isSecure() && isProxied()
? new DefaultProtocolSocketFactory()
: protocolInUse.getSocketFactory());

 

Why is this restiction in place? 

regards, 
John.  

John Melody 
SyberNet Ltd. 
Galway Business Park, 
Dangan, 
Galway. 
Tel. No. +353 91 514400 
Fax. NO. +353 91 514409 
Mobile - 087-2345847 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: question re: cookies

[Roland Weber]

Oleg, thanks for the hint.

Gil, if you're using version 2.0, instead of
hacking the HttpClient code, you can go
where others have gone before: write your
own GetMethod/PostMethod.
Just derive the regular ones, then override
addCookieRequestHeader() to do nothing.
Then you can setHeader() your cookies.

Optionally, you can also override method
processResponseHeaders() to do nothing,
so the incoming set-cookie headers will not
be parsed either.

cheers,
  Roland






"Kalnichevski, Oleg" <[EMAIL PROTECTED]>
25.03.2004 09:29
Please respond to "Commons HttpClient Project"
 
To: "Commons HttpClient Project" 
<[EMAIL PROTECTED]>
cc: 
Subject:RE: question re: cookies



Gil, Roland
Pluggable cookie policies as well as ability to manually set cookie 
headers are supported in the development branch only. For 2.0 there is no 
way around forking HttpClient

Oleg

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 8:39
To: Commons HttpClient Project
Subject: RE: question re: cookies


Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.

cheers,
  Roland






"Alvarez, Gil" <[EMAIL PROTECTED]>
25.03.2004 08:04
Please respond to "Commons HttpClient Project"


To: "Commons HttpClient Project"

<[EMAIL PROTECTED]>
cc:

Subject:RE: question re: cookies


Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader("Cookie", ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]

Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies

Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





***
The information in this email is confidential and may be legally 
privileged.  Access to this email by anyone other than the intended 
addressee is unauthorized.  If you are not the intended recipient of this 
message, any review, disclosure, copying, distribution, retention, or any 
action taken or omitted to be taken in reliance on it is prohibited and 
may be unlawful.  If you are not the intended recipient, please reply to 
or forward a copy of this message to the sender and delete the message, 
any attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

RE: question re: cookies

[Kalnichevski, Oleg]

Gil, Roland
Pluggable cookie policies as well as ability to manually set cookie headers are 
supported in the development branch only. For 2.0 there is no way around forking 
HttpClient

Oleg

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 25, 2004 8:39
To: Commons HttpClient Project
Subject: RE: question re: cookies


Ah yes, cookie headers that were manually set used
to get overridden. As far as I remember, that changed
a while back. Though I cannot tell whether the change
went into 2.0 or only into the development branch.

cheers,
  Roland






"Alvarez, Gil" <[EMAIL PROTECTED]>
25.03.2004 08:04
Please respond to "Commons HttpClient Project"

To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
Subject:RE: question re: cookies


Thanks, yes, the old code pulled it out of the header directly, but the
rest of the story is that I save that cookie for later submittal in a
url request. I tried using addRequestHeader("Cookie", ...) and that
didn't work. I surmised that it was because httpclient liked to operate
with higher-level abstractions, so I switched to using real Cookie
objects. I'd much rather do a getHeader()/setHeader() operation or
getCookie()/setCookie()operation; I don't want to mix the semantics
(such as getHeader()/setCookie()). Sounds like the cookie policy is the
way to go.

-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 10:51 PM
To: Commons HttpClient Project
Subject: Re: question re: cookies

Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





***
The information in this email is confidential and may be legally privileged.  Access 
to this email by anyone other than the intended addressee is unauthorized.  If you are 
not the intended recipient of this message, any review, disclosure, copying, 
distribution, retention, or any action taken or omitted to be taken in reliance on it 
is prohibited and may be unlawful.  If you are not the intended recipient, please 
reply to or forward a copy of this message to the sender and delete the message, any 
attachments, and any copies thereof from your system.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]