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