Agreed. This would be a better choice, as least for the short term.
Mike
On Mar 28, 2004, at 5:55 PM, [EMAIL PROTECTED] wrote:
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 pr
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 Samp
e-
From: Michael Becke [mailto:[EMAIL PROTECTED]
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 str
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
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 t
You are right. HttpClient uses tunnelling only when doing HTTPS. Hence the confusion.
-Original Message-
From: Roland Weber [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 15:03
To: Commons HttpClient Project
Subject: RE: Tunneling non-HTTP through a web proxy with HttpClient
Hi
o "Commons HttpClient Project"
To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
Subject: RE: Tunneling non-HTTP through a web proxy with
HttpClient
All Mikes, Roland, and all
I believe it _might_ be possible to implement
ke <[EMAIL PROTECTED]>
26.03.2004 14:44
Please respond to "Commons HttpClient Project"
To: "Commons HttpClient Project"
<[EMAIL PROTECTED]>
cc:
Subject: Re: Tunneling non-HTTP through a web proxy with
HttpClient
> Hi Mik
-Original Message-
From: Michael Becke [mailto:[EMAIL PROTECTED]
Sent: Friday, March 26, 2004 14:44
To: Commons HttpClient Project
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
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 f
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 specifica
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 us
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
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).
14 matches
Mail list logo
